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Abstract:  A  new  formal  model  is  presented,  for  studying  concurrency  and  resiliency  properties  for  nested 
transactions,  'fhc  model  is  used  to  state  and  prove  correctness  of  a  well-known  locking  algorithm. 

I.  Introduction 

This  paper  develops  the  foundation  for  a  general  theory  of  nested  transactions.  We  present  a  simple  formal 
model  for  studying  concurrency  and  resiliency  in  a  nested  environment  I  his  model  has  distinct  advantages 
over  the  many  alternatives,  the  greatest  of  which  is  the  unification  of  a  subject  replete  with  formalisms, 
correctness  conditions  and  proof  techniques.  'ITic  authors  arc  prcscnUy  engaged  in  an  ambitious  project  to 
recast  the  substantia I  amount  of  work  in  nested  transactions  within  this  single  intuitive  framework.  ITicse 
pages  contain  the  preliminary  results  of  that  project  -  a  description  of  the  model,  and  its  use  in  stating  and 
proving  correctness  conditions  for  two  variations  of  a  well-known  algorithm.  _ _ 

I  "he  model  is  based  on  I/O  automata .  a  simple  formalization  of  communicating  automata.  It  is  not  complex 
-  it  is  easily  presented  in  a  few  pages,  and  easy  to  understand,  given  a  minimal  background  in  automata 
theory.  Hach  nested  transaction  and  data  object  Ls  modelled  by  a  separate  I/O  automaton.  'Ihcsc  automata, 
the  system  primitives,  issue  requests  to  and  receive  replies  from  some  scheduler,  which  is  simply  another  I/O 
automaton.  Simple  syntactic  constraints  on  the  interactions  of  these  automata  ensure,  for  example,  that  no 
transaction  requests  the  creation  of  the  same  child  more  than  once.  One  scheduler,  in  this  case  the  "serial 
scheduler",  interacts  with  the  transactions  and  objects  in  a  particularly  constrained  way.  The  "serial 
schedules"  of  the  primitives  and  the  serial  scheduler  arc  the  basis  of  our  correctness  conditions.  Specifically, 
alternative  schedulers  arc  required  to  ensure  that  nested  transaction  automata  individually  have  local 
schedules  which  they  could  have  in  a  serial  schedule.  In  essence,  each  scheduler  must  "fool”  the  transactions 
into  believing  that  the  system  is  executing  in  conjunction  with  the  serial  scheduler. 

In  the  past  ten  years,  an  important  and  substantial  body  of  work  has  appeared  on  the  design  and  analysis  of 
algorithms  for  implementing  concurrency  control  and  resiliency  in  database  transaction  systems 


[I'Xil  T.RI  S.liG.KS.Gr.l  aS,  etc.).  Among  this  has  been  a  number  of  results  dealing  with  nested  transactions 
|R.Mo.l.iS.I.IIJI.SW.AM.HHGI.S.IIHG,  clc.].  The  present  work  docs  not  replace  these  other  contributions, 
but  augments  them  by  providing  a  unifying  and  mathematically  tractable  framework  for  posing  and  exploring 
a  variety  of  questions.  This  previous  work  uses  behavioral  specifications  of  nested  transactions,  focusing  on 
what  nested  transactions  do.  raUicr  than  what  they  arc.  liy  answering  the  question  "What  is  a  nested 
transaction?”.  I/O  automata  provide  a  powerful  tool  for  understanding  and  reasoning  about  them. 

Some  unification  is  vitally  important  to  further  development  in  this  field.  The  plethora  and  complexity  of 
existing  formalizations  is  a  challenge  to  the  most  seasoned  researcher.  More  critically,  it  belies  the  argument 
diat  nested  transactions  provide  a  clean  and  intuitive  tool  for  organizing  distributed  databases  and  more 
general  distributed  applications.  It  is  particularly  important  to  provide  an  intuitive  and  precise  description  of 
nested  transactions  themselves,  as  in  typical  systems,  these  arc  the  components  which  the  application 
programmer  must  implement! 

Ihc  remainder  of  this  paper  is  organized  as  follows.  ’Ihc  I/O  automaton  model  is  described  in  Section  2. 
The  rest  of  the  paper  contains  an  extended  example,  which  establishes  correctness  properties  for  two  related 
lock-based  concurrent  schedulers. 

Section  3  contains  simple  definitions  for  naming  nested  transactions  and  objects,  and  for  specifying  the 
operations  (interactions)  of  these  components.  Simple  syntactic  restrictions  on  the  orders  of  these  operations 
arc  presented,  and  then  a  particular  system  of  I/O  automata  is  presented,  describing  the  interactions  of  nested 
transactions  and  objects  with  a  serial  scheduler.  The  interface  between  the  serial  scheduler  and  the 
transactions  provides  a  basis  for  the  specification  of  correctness  conditions  for  alternative  schedulers.  These 
schedulers  would  presumably  be  more  efficient  than  the  serial  scheduler,  'fhc  strongest  correctness  condition, 
"serial  correctness.”  requires  that  all  non-access  transactions  see  serial  behavior  at  their  interface  with  the 
system.  The  second  condition,  "correctness  for  T0,"  only  requires  that  this  serial  interface  be  maintained  at 
the  interface  of  the  system  and  the  external  world.  ITicsc  interfaces  also  provide  simple  descriptions  of  the 
environment  in  which  nested  transactions  can  be  assumed  to  execute.  A  particular  contribution  is  the  clear 
and  concise  semantics  of  ABORT  operations  which  arises  naturally  from  this  formalization.  The  section 
closes  with  a  collection  of  lemmas  describing  useful  properties  of  serial  systems. 

Next,  a  lock-based  concurrent  system  is  presented.  Section  4  contains  a  description  of  a  special  type  of 
object,  called  a  "resilient  object",  which  is  used  in  the  concurrent  system.  Section  5  describes  the  remainder 
of  the  concurrent  system,  the  "concurrent  scheduler,"  This  concurrent  scheduler  includes  "lock  manager" 
modules  for  all  the  objects;  lock  managers  coordinate  concurrent  accesses. 
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Section  6  defines  a  system  which  is  closely  related  to  die  concurrent  system,  die  "weak  concurrent  system.” 
This  system  preserves  serial  correctness  for  those  transactions  whose  ancestors  do  not  abort  (i.e  diosc  that  arc 
not  "orphans").  Since  the  root  of  the  transaction  tree.  T(J,  has  no  ancestor,  weak  concurrent  systems  arc 
correct  for  T'0.  Section  7  contains  complete  proofs  of  correctness  of  the  concurrent  and  weak  concurrent 
sytems:  concurrent  systems  are  serially  correct,  and  weak  concurrent  systems  arc  correct  for  T'0.  The  stronger 
condition  is  obtained  for  concurrent  systems  as  a  corollary  to  a  result  about  weak  concurrent  systems. 

It  is  interesting  that  the  concurrent  system  algorithms  arc  described  in  complete  detail  (essentially,  in 
"pseudocode”),  yet  significant  formal  claims  about  their  behavior  can  be  stilted  clearly  and  easily.  Although 
the  full  presentation  involves  a  large  number  of  lemmas,  the  ideas  described  by  the  lemmas  arc  quite  simple 
and  intuitive.  We  think  it  is  remarkable  that  these  interesting  properties  of  concurrent  systems  can  be  proved 
with  complete  rigor,  in  full  detail,  in  so  short  a  development.  Despite  the  detailed  level  of  presentation,  the 
underlying  model  is  general  enough  that  the  results  apply  to  a  wide  range  of  implementations. 

I  Tic  style  of  the  correctness  pnxif  is  also  noteworthy.  It  is  a  constructive  proof,  in  that  for  each  step  of  the 
weak  concurrent  system  and  each  non-orphan  transaction,  an  execution  of  the  serial  system  is  explicitly 
constructed.  The  transaction's  local  "view”  in  the  constructed  execution  is  identical  to  that  in  the  original 
weak  concurrent  execution,  establishing  the  correctness  of  the  weak  concurrent  system.  One  may  think  of  the 
weak  concurrent  system  as  maintaining  consistent,  parallel  "world  views"  within  which  concurrent  siblings 
execute.  As  siblings  return  to  their  parent,  these  parallel  worlds  arc  "merged"  to  form  a  single  consistent 
view.  The  locking  policy  prevents  collisions  between  different  views  at  the  shared  data.  This  intuition  is 
strongly  supported  and  clarified  by  the  correctness  proof,  which  constructs  the  parallel  views  as  different 
serial  schedules  consistent  with  each  sibling's  local  history.  I  .emmas  illustrate  how  these  serial  schedules  can 
be  merged  as  siblings  return  or  abort  to  their  parent 

Section  8  contains  a  discussion  of  the  relationship  of  this  work  to  previous  results,  and  Section  9  contains  an 
indication  of  the  work  that  lies  ahead. 

2.  Basic  Model 

In  this  section,  we  present  the  basic  I/O  automaton  model,  which  is  used  to  describe  all  components  of  our 
systems.  This  model  consists  of  rather  standard,  possibly  infinite-state,  nondctcrministic  automata  that  have 
operation  names  associated  with  their  state  transitions.  Communication  among  automata  is  described  by 
identifying  their  operations.  This  model  is  very  similar  to  models  used  by  Milner,  Hoarc  (Mi,Ho)  and  others. 
There  arc  a  few  differences:  first,  we  find  it  important  to  classify  operations  of  any  automaton  or  system  of 
automata  as  either  "input"  or  "output"  operations,  of  that  automaton  or  system,  and  we  treat  these  two  eases 
differently.  Also,  we  allow  identification  of  arbitrary  numbers  of  operations  from  different  automata,  rather 
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than  just  pairwise  identification  as  considered  in  [Mi]. 

This  paper  is  not  intended  to  develop  the  basic  model.  For  die  general  theory  of  I/O  automata,  including  a 
unified  treatment  of  finite  and  infinite  behavior,  we  refer  the  reader  to  [I.T],  In  the  present  treatment  of 
concurrent  transaction  systems,  we  only  prove  properties  of  finite  behavior,  so  we  only  require  a  simple 
special  ease  of  the  general  model. 

II.  I/O  Automata 

All  components  in  our  systems,  transactions,  objects  and  schedulers,  will  be  modelled  by  I/O  automata.  An 
I/O  automaton  A  has  components  states! A).  slartf  Ji).  out(A).  in(A).  and  steps! A).  Mere,  states! A)  is  a  set  of 
states,  of  which  a  subset  start! A)  is  designated  as  the  set  of  start  states.  The  next  two  components  arc  disjoint 
sets:  out! A)  is  the  set  of  output  operations .  and  in! A)  >s  the  set  of  input  operations.  The  union  of  these  two 
sets  is  the  set  of  operations  of  the  automaton.  Finally,  steps! A)  is  the  transition  relation  of  A.  which  is  a  set  of 
triples  of  the  form  (s’.ir.s),  where  s'  and  s  arc  states,  and  w  is  an  operation.  Ihis  triple  means  that  in  state  s’, 
the  automaton  can  atomically  do  operation  w  and  change  to  state  s.  An  element  of  the  transition  relation  is 
called  a  step  of  A. 

The  output  operations  arc  intended  to  model  the  actions  that  arc  triggered  by  the  automaton  itself,  while 
the  input  operations  model  the  actions  that  arc  triggered  by  the  environment  of  the  automaton.  Our 
partitioning  of  operations  into  input  and  output  indicates  that  each  operation  is  only  triggered  in  one  place. 
We  require  the  following  condition. 

Input  Condition:  F'or  each  input  operation  w  and  each  state  s',  there  exist  a  state  s  and  a  step  (s\ir,s). 

Ihis  condition  says  that  an  I/O  automaton  must  be  prepared  to  receive  any  input  operation  at  any  time. 
'Ihis  condition  makes  intuitive  sense  if  we  think  of  the  input  operations  as  being  triggered  externally.  (In  this 
paper,  this  condition  serves  mainly  as  a  technical  convenience,  but  in  [l.'l],  where  infinite  behavior  is 
considered,  it  is  critical.) 

An  execution  of  A  is  an  alternating  sequence  s^w  (,  Sj,w2„..  of  states  and  operations  of  A:  the  sequence  may 
be  infinite,  but  if  it  is  finite,  it  ends  with  a  stale.  Furthermore.  s0  is  in  start(jt),  and  each  triple  (s\*.s)  which 
occurs  as  a  consecutive  subsequence  is  a  step  of  A.  From  any  execution,  we  can  extract  the  schedule,  which  is 
the  subsequence  of  the  execution  consisting  of  operations  only.  Because  transitions  to  different  states  may 
have  the  same  operation,  different  executions  may  have  the  same  schedule. 

l/cmma  1:  If  a  is  a  schedule  of  I/O  automaton  A,  then  every  prefix  of  a  is  a  schedule  of  A. 


If  S  is  any  set  of  schedules  (or  properly  of  schedules),  then  A  is  said  to  preserve  S  provided  that  the 
following  holds.  If  a  =  an  is  any  schedule  of  A .  where  v  is  an  output  operation,  and  a'  is  in  S.  then  a  is  in 
S.  That  is,  the  automaton  is  not  the  first  to  violate  the  property  described  by  S. 

2.2.  Composition  of  Automata 

We  describe  systems  as  consisting  of  interacting  components,  each  of  which  is  an  I/O  automaton.  It  is 
convenient  and  natural  to  view  systems  as  I/O  automata,  also.  Thus,  we  define  a  composition  operation  for 
I/O  automata,  to  yield  a  new  I/O  automaton. 

A  set  of  I/O  automata  may  be  composed  to  create  a  system  f.  if  all  of  the  output  operations  arc  disjoint. 
('Ihus.  every  output  operation  in  If  will  be  triggered  by  exactly  one  component.)  The  system  If  is  itself  an  I/O 
automaton.  A  suite  of  the  composed  automaton  is  a  tuple  of  states,  one  for  each  component,  and  the  start 
suites  arc  tuples  consisting  of  suirt  suites  of  the  components.  The  set  of  operations  of  If.  opsff, ),  is  exactly  the 
union  of  the  sets  of  operations  of  the  component  automata.  The  set  of  output  operations  of  If.  oulff),  is 
likewise  the  union  of  the  sets  of  output  operations  of  the  component  automata.  Kinally,  the  set  of  input 
operations  of  If,  inf  If),  is  opsff)  -  uut(f),  the  set  of  operations  of  If  that  arc  not  output  operations  of  If.  ’Ilie 
output  operations  of  a  system  arc  intended  to  be  exactly  those  that  arc  triggered  by  components  of  the  system, 
while  the  input  operations  of  a  system  arc  those  that  arc  triggered  by  the  system’s  environment 

The  triple  (s’,ir.s)  is  in  the  transition  relation  of  I f  if  and  only  if  for  each  component  automaton  A,  one  of  the 
following  two  conditions  holds.  Hither  ir  is  an  operation  of  A.  and  the  projection  of  the  step  onto  A  is  a  step 
of  A,  or  else  w  is  not  an  operation  of  A,  and  the  suites  corresponding  to  A  in  the  two  tuples  s’  and  s  arc 
identical.  Thus,  each  operation  of  the  composed  automaton  is  an  operation  of  a  subset  of  the  component 
automata.  During  an  operation  n  of  If.  each  of  the  components  which  has  operation  n  carries  out  the 
operation,  while  the  remainder  stay  in  the  same  state.  Again,  the  operation  v  is  an  output  operation  of  the 
composition  if  it  is  the  output  operation  of  a  component  -  otherwise,  ir  is  an  input  operation  of  the 
composition.1 

Iximma  2:  The  composition  of  I/O  automata  is  an  I/O  automaton. 

ITic  next  lemma  allows  us  to  compose  automata  in  any  order. 

tamma  3:  Up  to  isomorphism,  composition  of  I/O  automata  is  associative  and  commutative. 


Note  that  our  model  has  chosen  a  particular  convention  for  identifying  operations  of  different  components  in  a  system:  we  simply 
identify  those  with  the  same  name.  This  convention  is  simple,  and  sufficient  for  what  we  do  in  this  paper  However,  when  this  work  is 
extended  to  more  complicated  systems,  it  may  be  expedient  to  generalize  the  convention  for  identifying  operations,  to  permit  reuse  of  the 
same  operation  name  internally  to  different  components.  Ibis  will  require  introducing  a  renaming  operator  for  operations,  or  else 
defining  composition  with  respect  to  a  designated  equivalence  relation  on  operations.  We  leave  this  for  later  work. 
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An  execution  of  a  syslcm  is  defined  to  he  an  execution  of  the  automaton  composed  of  the  individual 
automata  of  the  system.  If  a  is  a  schedule  of  a  system  with  component  A,  then  we  denote  by  a|-4.  the 
subsequence  of  a  containing  all  the  operations  of  .A.  Clearly.  a|.X  is  a  schedule  of  A. 

Lemma  4:  Let  a  be  a  schedule  of  a  system  f.  and  let  a  =  a  ' it.  where  it  is  an  output  operation 
of  component  A.  If  «j  A  is  a  schedule  of  A.  then  a  is  a  schedule  of  $. 

Proof:  Since  a\A  is  a  schedule  of  A.  there  is  an  execution  ft  of  A  with  schedule  a|-4..  Let  /?*  be 
the  execution  of  A  consisting  of  all  but  the  last  step  of/?.  Similarly,  since  a'  is  a  schedule  of  f. 
there  is  an  execution  y  of  f  with  schedule  a'.  It  is  possible  that  A  has  an  execution  in  y  which  is 
different  from  /?'.  since  different  executions  may  have  the  same  schedule,  Ilut  it  is  easy  to  show, 
by  induction  on  die  length  of  y,  that  there  is  another  execution  y'  of  f  in  which  component  A  has 
execution  /?’.  and  which  is  otherwise  identical  to  y.  the  schedule  of  y'  is  a'.  Since  it  is  not  an 
output  operation  of  any  other  component,  it  is  defined  from  the  state  reached  at  the  end  of  y\  so 
that  a  =  a' ir  is  a  schedule  off.  I 


3.  Serial  Systems 

In  this  paper,  we  define  three  kinds  of  systems:  "serial  systems"  and  two  types  of  "concurrent  systems". 
Serial  systems  describe  serial  execution  of  transactions.  Serial  systems  arc  defined  for  the  purpose  of 
providing  a  correctness  condition  for  other  systems:  that  the  schedules  of  the  other  systems  should  "look 
like"  schedules  of  the  serial  system  to  the  transactions.  As  with  serial  schedules  of  single-level  transaction 
systems,  our  serial  schedules  arc  too  inefficient  to  use  in  practice.  Thus,  we  define  systems  which  allow 
concurrency,  and  which  permit  the  abort  of  transactions  after  they  have  performed  some  work.  We  then 
prove  that  the  schedules  permitted  by  concurrent  systems  arc  correct 

In  this  section,  we  define  "serial  systems".  Serial  systems  consist  of  "transactions"  and  "basic  objects” 
communicating  with  a  "serial  scheduler".  Transactions  and  basic  objects  describe  user  programs  and  data, 
respectively.  The  serial  scheduler  controls  communication  between  the  other  components,  and  thereby 
defines  the  allowable  orders  in  which  the  transactions  may  lake  steps.  All  three  types  of  system  components 
arc  modelled  as  I/O  automata. 

We  begin  by  defining  a  structure  which  describes  the  nesting  of  transactions.  Namely,  a  system  type  is  a 
four-tuple  (®Tparcnt,0,V),  where  the  set  of  transaction  names,  is  organized  into  a  tree  by  the  mapping 
parent:^ -+  with  Tfl  as  the  root  In  referring  to  this  tree,  we  use  traditional  terminology,  such  as  child,  leaf, 
least  common  ancestor  (lea),  ancestor  and  descendant  (A  transaction  is  its  own  ancestor  and  descendant) 
TTic  leaves  of  this  tree  are  called  accesses.  The  set  0  denotes  the  set  of  objects:  formally,  0  is  a  partition  of  the 
set  of  accesses,  where  each  element  of  the  partition  contains  the  accesses  to  a  particular  object  'Lhc  set  V  is  a 
set  of  values,  to  be  used  as  return  values  of  transactions. 

The  tree  structure  can  be  thought  of  as  a  predefined  naming  scheme  for  all  possible  transactions  that  might 
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ever  he  invoked.  In  any  particular  execution,  however,  only  some  of  these  transitions  will  actually  take 
steps.  We  imagine  that  the  tree  structure  is  known  in  advance  by  all  components  of  a  system.  The  tree  will,  in 
general,  be  an  infinite  structure. 

The  classical  transactions  of  concurrency  control  theory  (without  nesting)  appear  in  our  model  as  the 
children  of  a  "mythical"  transaction,  l'0.  the  root  of  the  transaction  tree.  (In  work  on  nested  transactions,  such 
as  ARGUS  |l.iS.I.IIJI.SW),  the  children  ofl'0  arc  often  called  "top-level"  transactions.)  It  is  very  convenient 
to  introduce  the  new  root  transaction  to  model  the  environment  in  which  the  rest  of  the  transaction  system 
runs.  Transaction  Tfl  has  operations  that  describe  the  invocation  and  return  of  the  classical  transitions.  It  is 
natural  to  reason  about  TQ  in  much  the  same  way  as  about  all  of  the  other  transitions,  although  it  is 
distinguished  from  the  other  transactions  by  having  no  parent  transaction.  Since  committing  and  aborting  arc 
operations  which  take  place  at  the  parent  of  each  transaction  (see  below),  1'  can  neither  commit  nor  abort 
Thus,  a  commit  or  abort  of  a  top-level  transaction  to  Tfl  is  an  irreversible  step. 


ft 
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The  internal  nodes  of  the  tree  model  transactions  whose  function  is  to  create  and  manage  subtransactions, 
but  not  to  access  data  directly.  The  only  transactions  which  actually  access  data  arc  the  leaves  of  the 
transaction  tree,  and  thus  they  arc  distinguished  as  "accesses".  The  partition  0  simply  identifies  those 
transactions  which  access  the  same  object 

A  serial  system  of  a  given  system  type  is  the  composition  of  a  set  of  I/O  automata.  This  set  contains  a 
transaction  for  each  internal  (i.c.  non-leaf,  non-access)  node  of  the  transaction  tree,  a  basic  object  for  each 
element  of  0  and  a  serial  scheduler.  These  automata  arc  described  below.  (If  X  is  a  basic  object  associated 
with  an  element  96  of  the  partition  0,  and  T  is  an  access  in  96,  we  write  T  €  accessesfX)  and  say  that  "T  is  an 
access  to  X”.) 


3.1.  Transactions 

This  paper  differs  from  earlier  work  such  as  [l.y,Go,Wcl]  in  that  we  model  the  transactions  explicitly,  as 
I/O  automata.  In  modelling  transactions,  we  consider  it  very  important  not  to  constrain  them  unnecessarily; 
thus,  we  do  not  want  to  require  that  they  be  expressible  as  programs  in  any  particular  high-level  programming 
language.  Modelling  the  transactions  as  I/O  automata  allows  us  to  state  exactly  the  properties  that  are 
needed,  without  introducing  unnecessary  restrictions  or  complicated  semantics. 

A  non-access  transaction  1'  is  modelled  as  an  I/O  automaton,  with  the  following  operations. 

Input  operations: 

CRK  All-XT) 

COMMIT(T\v),  forT  €  childrcn(T) and  v  €  V 
AIIORTCD,  for  I"  €  childrcn(T) 


Output  operations: 

RIQUFST-CRHATFXr).  for  T  €  childrcn(T) 

RHQUHST-COMMH(T.v).  for  v  €  V 

The  CRHATH  input  operation  "wakes  up"  the  transaction.  The  RF.QUHS T— CRHATH  output  operation  is 
a  request  by  T  to  create  a  particular  child  trans;iction.2Thc  COMM  IT  input  operation  reports  to  T  the 
successful  completion  of  one  of  its  children,  and  returns  a  value  recording  the  results  of  that  child's  execution. 
The  AHORT  input  operation  reports  to  T  the  unsuccessful  completion  of  one  of  its  children,  without 
returning  any  other  information.  We  call  COMMITf T.v).  for  any  v,  and  ABORTfl")  return  operations  for 
transaction  T.  ITic  RHQUHST— COMMIT  operation  is  an  announcement  by  T  that  it  has  finished  its  work, 
and  includes  a  value  recording  the  results  of  that  work. 

It  is  convenient  to  use  two  separate  operations,  RHQUFST— CRHATH  and  CRHATH,  to  describe  what 
takes  place  when  a  subtransaction  is  activated.  ITic  RHQUHST— CR HATH  is  an  operation  of  the 
transaction's  parent  while  the  actual  CRHATH  takes  place  at  the  subtransaction  itself.  In  actual  systems  such 
as  ARGUS,  this  separation  docs  occur,  and  the  distinction  will  be  important  in  our  results  and  proofs.  Similar 
remarks  hold  for  the  RHQUHST -COM MIT  and  COMMIT  operations.3  We  leave  the  executions  of 
particular  transaction  automata  largely  unspecified;  the  choice  of  which  children  to  create,  and  what  value  to 
return,  will  depend  on  the  particular  implementation.  For  the  purposes  of  the  schedulers  studied  here,  the 
transactions  (and  in  large  part,  the  objects)  arc  "black  boxes."  Nevertheless,  it  is  convenient  to  assume  that 
schedules  of  transaction  automata  obey  certain  syntactic  constraints.  Thus,  transaction  automata  arc  required 
to  preserve  well-formedness,  as  defined  below. 

We  recursively  define  well-formedness  for  sequences  of  operations  of  transaction  T.  Namely,  the  empty 
schedule  is  well-formed.  Also,  if  a  =  a' w  is  a  sequence  of  operations  of  T,  where  ir  is  a  single  operation, 
then  a  is  well-formed  provided  that  a'  is  well-formed,  and  the  following  hold. 

•  If w  is  CRHATHfl).  then 

(i)  there  is  no  CRKATKCO  in  a. 

•  If  v  is  COMMIT(T\v)  or  AHORT(T)  for  a  child  T  of  T,  then 

2Nolc  that  there  is  no  provision  for  T  lo  pass  information  lo  it*  child  in  this  request.  In  a  programming  language.  T  might  be 
permitted  to  pass  parameter  values  lo  a  subtransaction.  Although  this  may  be  a  convenient  descriptive  aid.  it  is  not  necessary  to  include 
in  it  the  underlying  formal  model.  Instead,  we  consider  uansactioas  that  have  different  input  parameters  to  be  different  transactions. 

3Notc  that  we  do  not  include  a  RliQUIiST  -  AHORT  operation  for  a  transaction:  we  do  not  model  the  situation  in  which  a  transaction 
decides  that  its  own  existence  is  a  mistake.  Rather,  we  assign  decisions  to  abort  transactions  lo  another  component  of  the  system,  the 
scheduler.  In  practice,  the  scheduler  must  have  some  power  to  decide  lo  abort  transactions,  as  when  it  detects  deadlocks  or  failures.  In 
ARGUS,  transactions  arc  permitted  to  request  lo  abort:  we  regard  this  request  simply  as  a  "hint"  to  the  scheduler,  to  restrict  its  allowable 
executions  in  a  particular  way  'this  operation  could  be  made  explicit,  constraining  the  scheduler  lo  abort  the  requesting  transaction, 
without  substantively  changing  the  model  or  results. 
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(i)  REQUEST— CREATIXT)  appears  in  a’ and 

(ii)  ihcre  is  no  return  operation  for  I"  in  a'. 

•  If*  is  REQUEST -CREATE* T)  for  a  child  T  off.  then 

(i)  there  is  no  REQUEST-CREATI*  T)  in  a' 

(ii)  there  is  no  REQUEST— C0MM1T(T)  in  a'  and 

(iii) CREAIEXT)  appears  in  a. 

•  If*  is  a  REQUEST- COM  MIT  forT.  then 

(i)  tlicrc  is  no  REQUEST -COM  MIT  forT  in  a  and 

(ii)  CREATE*!)  appears  in  a. 


restrictions  arc  very  basic:  they  simply  say  that  a  transaction  docs  not  get  created  more  than  once, 
docs  not  receive  repeated  notification  of  the  fates  of  its  children,  docs  not  receive  conflicting  information 
about  the  fates  of  its  children,  and  docs  not  receive  information  about  the  fate  of  any  child  whose  creation  it 
has  not  requested;  also,  a  transaction  docs  not  perform  any  output  operations  before  it  has  been  created  or 
aflcr  it  has  requested  to  commit,  and  docs  not  request  the  creation  of  die  same  child  more  than  once.  Kxccpt 
for  these  minimal  conditions,  there  arc  no  restrictions  on  allowable  transaction  behavior.  For  example,  the 
model  allows  a  transaction  to  request  to  commit  without  discovering  the  fate  of  all  subtransactions  whose 
creation  it  has  requested.  Also,  a  transaction  can  request  creation  of  new  subtransactions  at  any  time,  without 
regard  to  its  slate  of  knowledge  about  subtransactions  whose  creation  it  has  previously  requested.  Particular 
programming  languages  may  choose  to  impose  additional  restrictions  on  transaction  behavior.  (An  example  is 
ARGUS,  which  suspends  activity  in  transactions  until  subtransactions  complete.)  However,  our  results  do  not 
require  such  restrictions. 

The  following  easy  lemma  summarizes  the  properties  of  well-formed  sequences  of  transaction  operations. 

lamina  5:  I  et  a  be  a  well-formed  sequence  of  operations  of  transaction  T.  Ilicn  the  following 
conditions  hold. 

1.  Tlic  first  operation  of  a  is  a  CREATEXT)  operation,  and  there  arc  no  other  CREATE 
operations. 

2.  If  a  REQUEST -COM  MIT  operation  occurs  in  o,  then  there  arc  no  later  output 
operations  in  a. 

3.  There  is  at  most  one  REQUEST-  CREATECH  operation  for  each  child  T  of  T,  in  «. 

4.  Every  return  operation  in  a  has  a  preceding  REQUEST— CREATE  operation  in  a  for  the 
same  child  transaction. 
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3.2.  Basic  Objects 

Recall  that  I/O  automata  arc  associated  with  non-access  transactions  only.  Since  access  transactions  model 

abstract  operations  on  shared  data  objects,  we  associate  a  single  I/O  automaton  with  each  object,  rather  than 

one  for  each  access.  The  operations  for  each  object  are  just  die  CRKATK  and  RKQUKST-COMMIT 

operations  for  all  the  corresponding  access  transactions.  Although  we  give  these  operations  the  same  names  as 

the  operations  of  non-access  transactions,  it  is  helpful  to  think  of  the  operations  of  access  transactions  in  other 

terms  also:  a  CRKATK  corresponds  to  an  invocation  of  an  operation  on  the  object,  while  a 

RKQUKST-COMMIT  corresponds  to  a  response  by  Lite  object  to  an  invocation.  Actually,  these  CRKATK 

and  RKQUKS T— COMMI  T  operations  generalize  the  usual  invocations  and  responses  in  that  our  operations 

carry  with  them  a  designation  of  the  position  of  the  access  in  the  transaction  tree.  We  depart  from  the 

traditional  notational  distinction  between  creation  of  subtransactions  and  invocations  on  objects,  since  the 

|  common  terminology  for  access  and  non-access  transactions  is  of  great  benefit  in  unifying  the  statements  and 

proofs  of  our  results.  Ihus.  a  basic  object  X  is  modelled  as  an  automaton,  with  the  following  operations. 

Input  operations: 

CRKATKfl’).  forT  in  acccsscs(X) 

Output  operations: 

RHQU  KST-  COM  M  IT(T,v),  for  T  in  acccsscs(X) 

Ihc  CRKATK  operation  is  an  invocation  of  an  access  to  the  object,  while  the  RKQUKST-COMMIT  is  a 
return  of  a  value  in  response  to  such  an  invocation. 

As  with  transactions,  while  specific  objects  arc  left  largely  unspecified,  it  is  convenient  to  require  that 
schedules  of  basic  objects  satisfy  certain  syntactic  conditions.  'Ihus.  each  basic  object  is  required  to  preserve 
well-formedness,  defined  below. 

Ixt  a  be  a  sequence  of  operations  of  basic  object  X.  Then  an  access  T  to  X  is  said  to  be  pending  in  a 
provided  that  there  is  a  CRKATKfl’).  but  no  RKQUKST-COMMIT  for  T,  in  a.  We  define  well-formedness 
for  sequences  of  operations  of  basic  objects  recursively.  Namely,  the  empty  schedule  is  well-formed.  Also,  if 
a  =  a’w  is  a  sequence  of  operations  of  basic  object  X.  where  w  is  a  single  operation,  then  a  is  well-formed 
provided  that  a  is  well-formed,  and  the  following  hold. 

•  If  *  is  CRKATKf  f).  then 

(i)  there  is  no  CRKATKf  0  in  a,  and 

(ii)  there  arc  no  pending  accesses  in  a'. 

•  If  w  is  RKQUKST-COMMIT  forT,  then 

(i)  there  is  no  RKQUKST-COMMIT  forT  in  a,  and 

(ii)  CRKATKf  I’)  appears  in  a\ 

! 
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Ih esc  restrictions  simply  say  dial  llic  same  access  docs  not  gel  created  more  than  once,  nor  docs  a  creation 
of  a  new  access  occur  at  a  basic  object  before  the  previous  access  has  completed  (i.c.  requested  to  commit): 
also,  a  basic  object  docs  not  respond  more  than  once  to  any  access,  and  only  responds  to  accesses  that  have 
previously  been  created. 

'Hie  following  easy  lemma  summarizes  the  properties  of  well-formed  sequences  of  basic  object  operations. 

Umuua  6:  Let  a  be  a  well-formed  sequence  of  operations  of  basic  object  X.  Then  a  consists  of 
alternating  CRKATK  and  RIQUKST— COMMIT  operations,  starling  with  a  CRKATK,  and  with 
each  consecutive  (CRKATK.RKQUKST— COM  M  IT)  pair  having  a  common  transaction. 

33.  Serial  Scheduler 

'Ihc  third  kind  of  component  in  a  serial  system  is  the  serial  scheduler.  'Ihc  serial  scheduler  is  also  modelled 
as  an  automaton.  Ihc  transactions  and  basic  objects  have  been  specified  to  be  any  I/O  automata  whose 
operations  and  behavior  satisfy  simple  syntactic  restrictions.  ’Ihc  serial  scheduler,  however,  is  a  fully  specified 
automaton,  particular  to  each  system  type.  It  runs  transactions  according  to  a  depth-first  traversal  of  the 
transaction  tree.  Ihc  serial  scheduler  can  choose  nondctcrministically  to  abort  any  transaction  after  its  parent 
has  requested  its  creation,  as  long  as  the  transaction  has  not  actually  been  created.  In  the  context  of  this 
scheduler,  the  "semantics"  of  an  AHORT(T)  operation  arc  that  transaction  T  was  never  created.  'Ihe 
operations  of  the  serial  scheduler  are  as  follows. 

Input  Operations: 

R  KQU  KST — CRKATHfT) 

RKQUKST-COMMIT(T.v) 

Output  Operations: 

CRKATKfD 

COMMIT(T,v) 

ABORT(T) 

Ihc  RKQUKST— CRKATK  and  R  KQU  KST -COM  MIT  inputs  arc  intended  to  be  identified  with  the 
corresponding  outputs  of  transaction  and  object  automata,  and  correspondingly  for  the  CRKATK.  COMMIT 
and  ABORT  output  operations.  Kach  state  s  of  the  serial  scheduler  consists  of  four  sets: 
create -rcqucstcd(s),  crcatcd(s),  commit- rcqucstcd(s),  and  rctumcd(s).  Ihc  set  commit- rcqucstcd(s)  is  a 
set  of  (transaction, value)  pairs.  'Ihc  others  arc  sets  of  transactions.  There  is  exactly  one  initial  state,  in  which 
the  set  create  -  requested  is  {TQ}.  and  the  other  sets  arc  empty. 

Ihc  transition  relation  consists  of  exactly  those  triples  (s'.ir,s)  satisfying  the  pre*  and  postconditions  below, 
where  v  is  the  indicated  operation.  For  brevity,  we  include  in  the  postconditions  only  those  conditions  on  the 
state  s  which  may  change  with  the  operation.  If  a  component  of  s  is  not  mentioned  in  the  postcondition,  (such 
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as  rcturned(s)  in  ihc  postcondition  lor  RI*QUEST-CRHATH(T)),  it  is  implicit  dial  the  set  is  the  same  in  s' 
and  s  (that  rcturncd(s')  =  reuimcd(s).  in  this  example).  Note  dial  here,  its  elsewhere,  we  have  tried  to  specify 
the  component  as  nondctcrministically  us  possible,  in  order  to  achieve  the  greatest  possible  generality  for  our 
results. 

•  RHQUHST-CRHATH(T) 

Postcondition: 

create- requcstcd(s)  =  create  -  rcqucstcd(s')  U  {T} 

•  RHQUHST— COMMIT(T,v) 

Postcondition: 

commit  -  rcqucstcd<s)  =  commit- requested^')  U  {(T.v)} 

•  CRKATHTO 

Precondition: 

T  €  create  -  rcqucstcd( s’)  -  createdfs') 
siblings!  I')  H  crcalcd(s')  C  reiurncd(s') 

Postcondition: 

crcatcd(s)  =  crcatcd(s  )  U  {T} 

•  COMMITfl.v) 

Precondition: 

(T.v)  €  commit- requested^') 

T  €  rctumcd(s’) 

childrcn(T)  D  create  -  requested!  s')  Q  returned!  s’) 

Postcondition: 

rctumcd(s)  =  rctumcd(s’)  U  {T} 

•  ABORTfT) 

Precondition: 

T  €  create-  requesters')  -  crcatcd(s’) 
siblings(T)  D  crcatcd(s')  Q  returned  s’) 

Postcondition: 

crcatcd(s)  =  created^’)  U  {'1} 
rctumcd(s)  =  rctumed(s’)  U  (T) 

The  input  operations.  RHQUHST- CREATE  and  RHQUHST -COM MIT.  simply  result  in  the  request 
being  recorded.  A  CRKA'ITi  operation  can  only  occur  if  a  corresponding  REQUEST— CR HATH  has 
occurred  and  the  CREATE  has  not  already  occurred.  The  second  precondition  on  the  CREATE  operation 
says  that  the  serial  scheduler  docs  not  create  a  transaction  undl  all  its  previously  created  sibling  transactions 
have  returned.  That  is.  siblings  are  run  sequentially.  The  precondition  on  the  COMMIT  operation  says  that 
the  scheduler  docs  not  allow  a  transaction  to  commit  to  its  parent  until  its  children  have  returned.  The 
precondition  on  the  ABORT  operation  says  that  the  scheduler  docs  not  abort  a  transaction  while  there  is 
activity  going  on  on  behalf  of  any  of  its  siblings.  'Ihat  is,  aborted  transactions  arc  run  sequentially  with 
respect  to  their  siblings.  The  next  lemma  relates  a  schedule  of  the  serial  scheduler  to  the  state  which  results 
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from  applying  that  schedule. 

I  ^mina  7:  Let  a  be  a  schedule  of  the  serial  scheduler,  and  let  s  be  a  suite  which  can  result  from 
applying  a  to  the  initial  suite.  Then  llic  following  conditions  arc  true. 

1. T  is  in  create  -  rcqucstcd(s)  exactly  if  T  =  T0  or  o  contains  a  RHQUHST-CRKATK(T) 
operation. 

2.  T  is  in  crcalcd(s)  exactly  if  a  contains  either  a  CRKA’ITX' T)  or  A 110 R' 1(1)  operation. 

3. (T,v)  is  in  commit- rcqucstcd(s)  exactly  if  a  contains  a  RKQUHST-COMMIT(T,v) 
operation. 

4.  T  is  in  rctumcd(s)  exactly  if  a  contains  a  return  operation  for  T. 

3.4.  Serial  Systems  and  Serial  Schedules 

In  this  subsection,  we  define  serial  systems  precisely  and  provide  some  useful  terminology  for  talking  about 
them. 

’Che  composition  of  transactions  with  basic  objects  and  the  serial  scheduler  for  a  given  system  type  is  called 
a  serial  system.  Define  the  serial  operations  to  be  those  operations  which  occur  in  the  serial  system: 
RKQUKST-CRKATKS.  RhXJUHST —COMMITS.  CRKATKS,  COM  MU'S  and  AIIORTS.  I  he  schedules 
of  a  serial  system  arc  called  serial  schedules.  'I he  non-access  transactions  and  basic  objects  arc  called  the 
system  primitives.  (Recall  that  each  basic  object  is  an  automaton  corresponding  to  a  set  of  access  transactions. 
Ihus,  individual  access  transactions  arc  not  considered  to  be  primitives.) 

Recall  that  the  operations  of  the  basic  objects  have  the  same  syntax  as  transaction  operations.  It  is 
convenient  to  refer  to  CRKATFXT)  and  RHQUKSX— COMMUXT),  when  T  is  an  access  to  basic  object  X, 
both  as  operations  of  transaction  T  and  of  object  X.  To  avoid  confusion,  it  is  important  to  remember  that 
there  is  no  transaction  automaton  associated  with  any  access  operation. 

For  any  serial  operation  w.  we  define  transact ionfvt)  to  be  the  transaction  at  which  the  operation  occurs. 
(For  CRKATFXT)  operations  and  RKQUEST-COMMIT  operations  for  T,  the  transaction  is  T,  while  for 
RKQUKST-CRKATKfO  operations,  and  COMMIT  and  ABORT  operations  for  T,  the  transaction  is 
parcnt(T).)  For  a  sequence  a  of  serial  operations,  transaction  a)  is  the  set  of  transactions  of  the  operations  in 

a. 


Two  sequences  of  serial  operations,  a  and  a,  are  said  to  be  equivalent  provided  that  they  consist  of  the 
same  operations,  and  a|P  =  a’|P  for  each  primitive  P.  Obviously,  this  yields  an  equivalence  relation  on 
sequences  of  serial  operations. 
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Wc  let  afl'  denote  the  subsequence  of  a  consisting  of  operations  whose  transaction  is  T.  even  if  T  is  an 
access,  (’litis  is  an  extension  of  the  previous  definition  of  afl.  as  accesses  arc  not  component  automata  of  the 
serial  system.) 

I. cl  a  be  a  sequence  of  serial  operations.  Wc  say  that  a  transaction  T  is  live  in  a  provided  that  a 
CRI-ATim  but  no  COMMIT(T.v)  or  AIIORT(T).  occurs  in  a.  Wc  say  that  transaction  T  is  visible  to  T  in  a 
provided  that  for  each  ancestor  ’I"*  of  T  which  is  a  proper  descendant  of  lca(T.T).  some  COMMIT(T\v) 
occurs  in  a.  (In  particular,  any  ancestor  of  T  is  visible  to  T  in  a.)  For  sequence  a  and  transaction  T.  let 
visibUia.T)  be  the  subsequence  of  a  consisting  of  operations  whose  transactions  arc  visible  to  T  in  a.  (’Ilicsc 
include  access  transactions  T.)  Wc  say  that  transaction  T  sees  everything  in  a  provided  that  visiblc(a,T)  =  a. 

Ihis  is  the  same  definition  of  visibility  as  appears,  in  a  different  model,  in  (I  y].  Visibility  captures  an 
intuitive  notion  suggested  by  the  name:  the  transactions  visible  to  a  transaction  T  in  a  arc  those  whose  effects 
T  is  permitted  to  "see”  in  a.  If  transaction  1'  is  visible  to  transaction  1'  in  a.  it  means  that  descendants  of  T 
may  have  passed  to  T  information  about  T,  obtained  by  accessing  objects  that  were  previously  accessed  by 
descendants  of  T\ 


If  a  is  a  sequence  of  operations,  not  necessarily  all  serial,  then  define  scrial(a)  to  be  the  subsequence  of  a 
consisting  of  the  serial  operations.  Wc  say  that  T  is  live  in  a  provided  that  it  is  live  in  scrial(a).  Wc  say  that  T 
is  visible  to  T  in  a  if  T  is  visible  to  T  in  scrial(a).  and  define  visiblcfa.'f)  to  be  visiblc(scrial(a),'r).  Also.  T 
sees  everything  in  a  provided  that  1’  sees  everything  in  scrial(a).  Similarly,  define  transaction(a)  = 
transaction(scriaKa)). 

A  sequence  a  of  serial  operations  is  said  to  be  well-formed  if  its  projection  at  every  primitive  is  well-formed. 

15.  Correctness  Condition 

Wc  use  serial  schedules  as  the  basis  of  our  correctness  definitions.  Namely,  wc  say  that  a  sequence  of 
operations  is  serially  correct  for  a  primitive  I*  provided  that  its  projection  on  P  is  identical  to  the  projection  on 
P  of  some  serial  schedule.  Wc  say  that  any  sequence  of  operations  is  serially  correct  if  it  is  serially  correct  for 
every  non-access  transaction.  That  is,  a  "looks  like"  a  serial  schedule  to  every  non-access  transaction. 


In  the  remainder  of  this  paper,  wc  define  two  systems:  concurrent  systems  and  weak  concurrent  systems. 
Wc  show  that  schedules  of  concurrent  systems  arc  serially  correct,  and  that  schedules  of  weak  concurrent 
systems  arc  serially  correct  for  Tfl. 

Ihus.  wc  use  the  serial  scheduler  as  a  way  of  describing  desirable  behavior,  just  as  serial  schedules  describe 
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desirable  behavior  in  more  classical  concurrency  control  settings  (those  without  nesting).  I  ben  serial 
correctness  plays  the  role  in  our  theory  that  scriali/abilily  plays  in  classical  settings. 

Motivation  for  our  use  of  serial  schedules  to  define  correctness  derives  from  the  simple  behavior  of  the 
serial  scheduler,  which  determines  the  sequence  of  interactions  between  the  primitives,  Fach  transaction  T  is 
created  only  after  parentf T)  requests  it.  no  siblings  of  T  arc  created  until  I  has  returned.  T  is  not  committed 
until  each  of  its  requested  children  has  itself  relumed,  and  I  is  not  aborted  until  each  of  its  created  siblings 
has  returned.  Ibc  result  is  a  depth-first  traversal  of  the  transaction  tree,  with  requests  flowing  down  and 
responses  flowing  up.  We  believe  this  depth-first  traversal  to  be  a  natural  notion  of  correctness  which 
corresponds  precisely  to  the  intuition  of  how  nested  transaction  systems  ought  to  behave.  Furthermore,  it  is  a 
natural  generalization  of  scrializability,  the  correctness  condition  generally  chosen  for  classical  transaction 
systems. 

Serial  correctness  is  a  condition  which  guarantees  to  implementors  of  transactions  that  their  code  will 
encounter  only  situations  which  can  arise  in  serial  executions.  Correctness  for  TR  is  a  natural  alternative, 
which  guarantees  only  that  the  external  world  will  encounter  only  situations  which  can  arise  in  serial 
executions.  'Ibis  condition  permits  less  constrained  implementations,  in  that  schedulers  in  such  systems  need 
not  insure  that  orphans  see  consistent  data.  On  the  other  hand,  in  such  systems  the  authors  of  transactions 
must  insure  that  their  programs  behave  well  even  if  they  see  inconsistencies.  (For  example,  orphans  that  see 
inconsistent  data  should  not  consume  too  many  system  resources,  garble  data  beyond  repair,  dispense  drugs 
or  initiate  military  hostilities.)  We  hope  this  work  will  provide  a  tool  for  exploring  the  inherent  costs  of 
different  correctness  conditions  such  as  these. 

Note  that  our  correctness  conditions  arc  defined  at  the  transaction  interface  only,  and  do  not  constrain  the 
object  interface.  We  believe  that  this  makes  the  conditions  more  meaningful  to  users,  and  more  likely  to 
suffice  for  a  large  variety  of  algorithms,  which  may  use  a  variety  of  back-out,  locking  or  version  schemes  to 
implement  objects.  Previous  work  has  focussed  on  correctness  conditions  at  the  object  interface  [KGLT,  etc.]. 
While  we  believe  that  object  interface  conditions  are  important  their  proper  role  in  the  theory  is  not  to  serve 
as  the  basic  correctness  condition.  Rather,  they  arc  useful  as  intermediate  conditions  for  proving  correctness 
of  particular  implementations:  such  conditions  can  be  shown  to  be  sufficient  in  combination  with  an 
appropriate  scheduler,  to  ensure  our  correctness  condition  at  the  transaction  interface.  This  observation  is  an 
important  unifying  contribution  of  our  work.  Our  current  research  is  focussing  on  demonstrating  the 
usefulness  of  this  approach,  for  a  variety  of  object  interface  correctness  conditions. 


'Ibc  serial  correctness  condition  says  that  a  schedule  o  must  look  like  a  serial  schedule  to  each  non-access 
transaction;  this  allows  for  the  possibility  that  a  might  look  like  different  serial  schedules  to  different  non- 
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access  transactions.  This  condition  may  at  first  seem  to  be  loo  weak.  It  may  seem  that  we  should  require  that 
all  transactions  see  a  projection  of  the  same  serial  schedule.  Hut  this  stronger  condition  is  not  satisfied  by  most 
of  die  known  concurrency  control  algorithms.  It  is  true  that  stronger  conditions  than  ours  can  sometimes  be 
proved,  but  such  conditions  arc  more  complicated  to  suite,  and  it  is  not  yet  clear  which  such  conditions  arc 
most  interesting. 

ITic  serial  correctness  condition  is  really  not  as  weak  as  it  may  seem  at  first  because  l'0.  the  root  transaction, 
is  included  among  the  transactions  to  which  a  must  appear  serial.  As  discussed  above,  transaction  Tfl  can  be 
thought  of  as  modelling  the  environment  in  which  the  rest  of  tire  transaction  system  runs.  Its 
RHQUKS' T-CRKATK  operations  correspond  to  the  invocation  of  top-level  transactions,  while  its  COMMIT 
and  A  BOR  I  operations  correspond  to  return  values  and  external  effects  of  those  transactions.  Since  a's 
projection  on  TQ  must  be  serial,  the  environment  of  the  transaction  system  will  see  only  results  that  could  arise 
in  a  serial  execution.  Indeed,  this  is  the  justification  of  the  correctness  condition  for  the  weak  concurrent 
system,  whose  schedules  arc  shown  to  be  correct  for  TQ.  but  not  necessarily  for  any  other  transaction. 

It  is  possible  to  use  a  different  serial  scheduler  as  a  basis  for  correctness  conditions.  For  example,  the 
scheduler  might  delay  creating  one  sibling  until  another  requests  to  return,  rather  than  until  it  actually  returns 
to  the  parent  [Wc2].  Such  a  scheduler  would  provide  less  information  to  the  parent  about  the  actual  order  in 
which  its  children  arc  executed,  and  consequently  provide  more  freedom  for  concurrent  schedulers  to 
schedule  various  events.  Timestamp-based  systems  such  as  [R]  may  support  this  weaker  correctness 
condition,  rather  than  the  one  described  above,  but  this  remains  to  be  studied. 


Our  approach  is  really  a  general  technique  for  studying  operating  system  algorithms.  A  simple,  intuitive 
and  inefficient  algorithm  (automaton)  is  used  to  specify  a  "contract"  between  the  users  and  implementor  of 
an  operating  system.  Ihc  user  is  guaranteed  that  applications  (transactions,  in  our  work)  which  are  correct 


when  run  with  the  simple  algorithm  will  also  be  correct  when  run  with  the  actual  operating  system,  which 
presumably  will  be  more  efficient.  On  the  other  hand,  the  implementor  also  has  a  formal  and  intuitive 
specification  of  the  user  interface. 


3.6.  Properties  of  Serial  Systeas 

In  this  subsection,  we  prove  a  number  of  lemmas  about  the  behavior  of  serial  systems.  ’ITicy  arc  collected 
here  for  reference  later  in  this  paper  and  in  future  work.  Most  of  the  lemmas  describe  properties  that  are 
quite  easy  to  understand  and  believe,  and  the  corresponding  proofs  arc  very  straightforward.  In  the  last 
paragraph  of  this  subsection,  there  arc  some  specialized  lemmas  that  arc  somewhat  more  difficult  These  arc 
used  in  the  proof  of  the  main  theorem  in  Section  7. 
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3.6.1.  Fundamental  Properties  or  Visibility 

The  first  few  lemmas  give  fundamental  properties  of  visibility  in  sequences  of  serial  operations.  In  this 
paragraph,  we  do  not  even  require  that  the  sequences  be  schedules  of  serial  systems,  but  only  that  they  be 
sequences  of  serial  operations.  Ihc  proofs  of  these  lemmas  arc  straightforward  from  the  definitions, 
lamina  8:  l.ct  a  be  a  sequence  of  serial  operations,  and  T.  T  and  F*  transactions. 

1.  If  F  is  a  descendant  of  T.  then  T  is  visible  to  T  in  a. 

2.  F  is  visible  to  T  in  a  if  and  only  if  T  is  visible  to  IcaflYO  in  a. 

3.  If  f"  is  visible  toT  in  a  and  T  is  visible  to'l'  in  a.  then  I"  is  visible  to  T  in  a. 

4.  If  F  is  a  descendant  of  T  and  T'  is  visible  to  T  in  a.  then  T”  is  visible  to  T  in  a. 

5.  If  T  is  a  descendant  of  T  and  T  is  visible  U)  F*  in  a.  then  T  is  visible  to  T“  in  a. 

6.  If  T  is  a  proper  descendant  of  T.  F*  is  visible  to  F  in  a.  but  F  is  not  visible  to  1'  in  a.  then 
F'  is  a  descendant  of  the  child  of  T  which  is  an  ancestor  of  T. 

I emma  9:  l  et  a  and  fi  be  sequences  of  serial  operations,  with  p  a  subsequence  of  a. 

1.  If  transaction  T  is  visible  to  transaction  T  in  ft.  then  it  is  visible  to  transaction  T  in  a. 

2.  If  operation  ir  is  in  visiblc(/J.T).  then  it  is  in  visiblcfa.T). 

lemma  10:  let  a,  a\  P  and  p'  be  sequences  of  serial  operations,  and  let  T  and  1'  be 
transactions. 

1.  If  a  is  equivalent  to  a,  and  T  is  visible  to  T  in  a.  then  F  is  visible  to  T  in  a\ 

2.  If  a  is  equivalent  to  a\  then  visiblc(a.T)  is  equivalent  to  visiblcfa’.T)- 

3.  If  P  is  equivalent  to  p\  then  a  -P  =  «-P\ 

4.  If  a  is  equivalent  to  a',  and  P  is  equivalent  to  p\  then  a-p  is  equivalent  to  a’  -  fi\ 

5.  If  p  =  visiblc(a,T),  then  T  sees  everything  in  p. 

6.  If  p  is  equivalent  to  visiblcfa.’O.  then  T  sees  everything  in  p. 

7.  If p  =  visiblcfa.T) and F  is  visible  to  Tin  a,  then  visiblc(/f.F)  =  visib!c(o,F). 

8.  If p  is  equivalent  to  visiblc(a,T).  p'  is  equivalent  to  visiblcfa.F),  and  F  is  visible  to  T  in  o, 
then  p’  is  equivalent  to  visiblcOS.F). 

lemma  II:  let  a  be  a  sequence  of  serial  operations,  and  let  T  and  F  be  transactions.  Then 
visiblcfa,  l')f F  is  equal  to  ap"  if  1"  is  visible  to  T  in  a.  and  is  equal  to  the  empty  string  otherwise. 

lemma  12: 1  .cl  aw  be  a  sequence  of  serial  operations,  where  w  is  a  single  operation.  Let  T  be  a 
transaction  and  assume  that  transaction w)  is  visible  to  T  in  aw.  Assume  that  w  is  not  a  COMMIT 
operation.  Ihcn  visiblcfaw.T)  =  visiblc(a,T)w. 


3.6.2.  Operations  in  Serial  Schedules 

The  lemmas  in  this  paragraph  describe  the  kinds  and  orders  of  operations  that  can  occur  in  well-formed 
serial  schedules.  In  the  next  paragraph,  we  show  that  all  serial  schedules  arc  well-formed,  so  that  all  these 
properties  actually  follow  just  from  the  fact  that  the  schedules  arc  serial. 

1 ,1'innia  13:  l.ct  a  he  a  well-formed  serial  schedule,  and  let  T  *  Tfl  be  a  transaction. 

1.  If  a  contains  any  operation  with  transaction  T.  then  a  contains  a 
RHQUHST -CRHATFXT). 

2.  If  a  contains  a  COMMIT  for  T.  then  a  contains  a  REQUEST -COM  MIT  for  T,  a 
CRKA  ITXT)  and  a  RLQUEST-CRKATFXT). 

3.  If  a  contains  an  AUORT(T).  then  a  contains  a  REQUEST- CRHATFXT). 

Proof:  Straightforward  from  wcll-fonncdncss  and  the  scheduler  preconditions.  I 

lemma  14:  Let  a  he  a  well-formed  serial  schedule,  and  T  a  transaction.  Assume  that  some 
descendant  of  T  is  in  transaction  a).  Then  the  following  hold. 

1.  CRKATFXT)  occurs  in  a. 

2.  If  T  *  l0.  then  RKQUHST-CRKATKCO  occurs  in  a. 

Proof:  1.  Ity  induction  on  the  length  of  a.  The  basis  is  easy,  let  a  =  air.  where  *  is  a  single 
operation,  and  assume  that  the  result  holds  for  a",  let  T  =  transaction* ),  and  let  T  be  any 
ancestor  of  T.  We  must  show  that  CRHATFXT)  occurs  in  a. 

Because  a  is  well-formed,  CRHATFXT)  occurs  in  a.  If  T  =  T.  we  are  done.  Otherwise, 
Lemma  13  implies  dial  REQUEST -CRHATFXT)  occurs  in  a.  TTiis  occurs  at  parcnt(T),  which  is 
a  descendant  of T.  'Ihc  inductive  hypothesis  then  implies  that  a  contains  a  CRKATFXT). 

2.  By  part  1.  and  lemma  13.  I 

lemma  15:  Let  a  be  a  serial  schedule,  and  let  T  be  a  transaction.  Then  a  cannot  contain  both  a 
CRHATFXT)  and  an  ABORT(T)  operation. 

Proof:  By  the  scheduler  preconditions.  I 

lemma  16:  let  a  be  a  well-formed  serial  schedule,  and  let  T  be  a  transaction.  If  ABORTCO 
occurs  in  a.  then  a  contains  no  operations  whose  transactions  arc  descendants  of  T. 

Proof:  Assume  the  contrary.  Then  lemma  14  implies  that  a  CRKA'ITX  I  )  operation  occurs  in  a. 

But  lemma  15  yields  a  contradiction.  I 

lemma  17:  Let  a  be  a  well-formed  serial  schedule,  and  let  T  *  be  a  transaction. 

1.  If  a  contains  a  RKQUFST- CRHATFXT),  but  docs  not  contain  a  return  operation  for  T, 
then  parcnt(T)  is  live  in  a. 

2.  If  T  is  live  in  a,  then  parcnt(T)  is  live  in  a. 

3.  If  a  contains  a  REQUEST— CRKATFXT)  but  docs  not  contain  a  CREATEfO  or  an 
ABORT(  I  ),  then  parentO’)  is  live  in  a. 
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Proof: 

1.  Well-formedness  implies  that  the  RKQUKS T- CR I ‘ATI ‘XT)  is  preceded  in  a  by  a 

CRKAThXparcnt!  T)).  Suppose  that  p.irenK T)  is  not  live  in  a.  t  hen  a  return  operation  for 
parent!!)  occurs  in  a.  By  l.ernma  15.  AKOKT(parcnUT))  cannot  appear  in  a.  Thus,  a 
COMMIT  operation  for  parent! T)  must  appear  in  «.  This  COMMIT  operation  for 
parent(T)  must  he  preceded  by  a  RHQUKST- COM  MIT  for  parent!  I  ).  by  the  scheduler 
preconditions.  By  well-formedness,  the  RKQUKS  T-COMMIT  for  parent!'!')  must  follow 
die  RHQUKST— CRKAThXT)  operation,  so  that  the  COMMI  T  for  parent!  T)  follows  the 
RHQUKST— CRKA’ITX’ T)  operation.  Then  by  die  scheduler  preconditions  for  the 

COM  MIT  operation,  there  must  be  a  return  operation  for  T  in  a.  a  contradiction. 

2.  Since  T  is  live  in  a,  CRKAThXT)  occurs  in  a  and  so  Lemma  13  implies  that 
RHQUKST— CRKAThXT)  occurs  in  a.  'Ihc  result  then  follows  from  part  l. 

3.  Since  there  is  no  CRKAThXT)  in  a.  there  can  be  no  RKQUKST-COMMIT  for  T,  by 
well-formedness.  Ihcn  there  can  be  no  COMMIT  for  T.  by  the  scheduler  preconditions. 
Ihc  result  follows  from  part  1. 

I 

lemma  18:  Let  a  be  a  well-formed  serial  schedule,  and  IclT  be  a  transaction. 

1.  If  a  contains  a  RHQUKST— CRKAThXT)  but  docs  not  contain  a  return  operation  for  T, 
then  any  proper  ancestor  of  T  is  live  in  a. 

2.  IfT  is  live  in  a.  then  any  ancestor  of  T  is  live  in  a. 

3.  If  a  contains  a  RHQUKST- CRKAThXT)  but  docs  not  contain  a  CRKATKfO  or  an 
ABOR  T!  I  ),  then  any  proper  ancestor  of  T  is  live  in  a. 

Proof:  By  repeated  use  of  lemma  17.  I 

lemma  19:  let  a  be  a  well-formed  serial  schedule,  and  let  T  and  T  be  transactions  with  T  a 
descendant  of 'T.  Assume  that  there  is  a  COMMI  T  operation  for  T  in  a. 

1.  If  a  RHQUKST— CRKA’TFXT)  occurs  in  a.  then  there  is  a  return  operation  for  T  in  a. 

2.  IfT  is  in  transaction(a),  then  there  is  a  COMMIT  operation  for  T  in  a. 

Proof: 

1.  By  lemma  18. 

2.  lemma  13  implies  that  RHQUKST — CRKATKfT)  occurs  in  o.  Part  1  then  implies  that 
there  is  a  return  operation  for  T  in  o.  Since  T  is  in  transaction(a).  lemma  16  implies  that 
there  cannot  be  an  ABOR  T!  P)  in  a.  Ihus,  there  is  a  COMMIT  for  T  in  a. 


lemma  20:  let  a  be  a  well-formed  serial  schedule. 

If  a  return  operation  for  T  is  in  a,  then  it  follows  all  operations  in  a  whose  transaction  is  T. 

Proof:  lemma  16  implies  the  result  if  an  ABORT(T)  occurs  in  a.  So  assume  that  a  COMMTT 
for  T  occurs  in  a.  'This  must  be  preceded  by  a  RHQUKST— COMMIT  for  T,  by  scheduler 
preconditions.  Well-formedness  implies  that  the  RHQUKST— COMMIT  is  preceded  by  a 


CRKATKfO.  and  is  nol  followed  by  any  oulput  operations  of  T.  Thus.  the  only  operations  of  T 
that  could  follow  the  RKQUKSI  -COMMI  T  arc  return  operations  for  children  off.  I.et  T  be  a 
child  of  T  for  which  a  return  operation  occurs  in  a.  By  scheduler  preconditions,  there  is  only  one 
return  operation  lor  T  in  a.  By  l  emma  13.  a  also  contains  a  REQUKST-CRKATKXT).  Since 
this  is  an  output  operation  off.  it  precedes  the  Rl  .QlIKS  T-COMMTT  for  T.  and  hence  precedes 
the  COMMI  T  for  T.  Then  the  scheduler  preconditions  imply  that  the  return  operation  for  T 
precedes  the  COMMIT  for T.  I 

l  emma  21: 1  ct  a  be  a  well-formed  serial  schedule. 

If  a  return  operation  for  T  is  in  a.  then  it  follows  all  operations  in  a  whose  transactions  arc 
descendants  of  T. 

Proof:  Since  a  return  operation  for  T  occurs  in  a.  we  have  T  *  Tfl.  I  ct  T  be  a  descendant  off, 
and  assume  for  the  sake  of  obtaining  a  contradiction  that  an  operation  v  with  transaction^ )  =  T 
occurs  after  the  return  for  T  in  a.  I  .ct  a  be  the  prefix  of  a  preceding  ». 

l  emma  16  implies  the  result  if  an  ABORTfO  occurs  in  a.  So  assume  that  a  COMMI  T  for  T 
occurs  in  a.  Hy  Lemma  13.  a'  contains  a  RKQUKST— CRKATKf l")  operation.  Then  Lemma  19 
implies  that  a'  contains  a  return  operation  for  T.  But  then  the  well-formed  schedule  aw  contains 
a  return  for  T  followed  by  an  operation  of  T.  which  contradicts  I  emma  20.  I 

U-mma  22:  Let  a  be  a  well-formed  serial  schedule.  Iff  is  a  pending  access  in  a|X.  then  f  is  live 
in  a. 

Proof:  If  T  is  a  pending  access  in  a|X.  then  a  CRKATKfO  occurs  in  a,  but  no 
REQUEST -COMM  IT  for  T  occurs  in  a.  'Iltus.  by  the  scheduler  preconditions,  no  COMMIT 
for  T  can  occur  in  a.  I 

lycmma  23:  l  et  a  be  a  well-formed  serial  schedule,  and  let  T  and  I"  be  distinct  transactions  live 
in  a.  Then  the  following  arc  true. 

1.  T  and  T  arc  not  siblings. 

2.  Either  T  is  an  ancestor  of  T  or  vice  versa. 

Proof: 

1.  Assume  the  contrary.  Assume  without  loss  of  generality  that  CRKATKfO  precedes 
CRKATLX’D  in  a.  'Then  the  scheduler  preconditions  for  the  CRKATKfO  operation 
imply  that  a  return  operation  for  T  occurs  in  a.  This  contradicts  the  assumption  that  T  is 
live  in  a. 

2.  By  part  1  and  Ijcmma  18. 

I 

3.6  J.  Well-Formedness 

Now  we  show  that  all  serial  schedules  arc  well-formed.  It  follows  that  all  the  properties  proved  in  the 
previous  paragraph  for  well-formed  serial  schedules  arc  actually  true  for  all  serial  schedules.  Subsequently, 
we  will  use  these  properties  without  explicitly  mentioning  well-formedness. 

tantma  24:  Let  a  be  a  serial  schedule.  'Ihcn  a  is  well-formed. 

Proof:  By  induction  on  the  length  of  schedules.  The  base,  length  =  0.  is  trivia'  Suppose  that 
an  is  a  serial  schedule,  and  assume  that  a  is  well-formed.  If  n  is  an  output  of  a  primitive  P.  then 


«w|P  is  wcll-fonncd  because  l’  preserves  well-formedness.  and  so  air  is  well-formed.  So  assume 
thal  it  is  an  input  to  a  primitive  I*.  It  suffices  to  show  that  null*  is  well-formed.  There  arc  four 
eases. 

( 1 )  ir  is  CRLATLfT)  and  T  is  a  non-access  transaction. 

The  scheduler  preconditions  insure  that  CRLATLfT)  docs  not  appear  in  a. 

(2)  w  isCOMMITfT.v)  for  some  transaction  l  and  value  v. 

Then  m  is  an  input  to  transaction  pnrcntfT)  =  T.  The  scheduler  preconditions  imply  that  a 
contains  a  RI-QULST— COMMITfT.v).  and  so  Lemma  B  implies  that  a  contains  a 
RliQUIiST— CRHATKfT).  Also,  the  scheduler  preconditions  imply  thal  no  return  operation  for 
T  occurs  in  a. 

(3)  w  is  ABORT(T)  for  some  transaction  T. 

Ihcn  v  is  an  input  to  transaction  parentfH  =  T.  'Ihc  scheduler  preconditions  imply  that  a 
contains  a  RliQUKST-CRHATHfT),  but  no  return  operation  for  T. 

(4)  v  is  CRLA'ILfT)  and  T  is  an  access  to  basic  object  X. 

Ily  die  scheduler  prcc«indilions.  no  CRLATLfT)  or  ABORTfT)  appears  in  a.  but  a 
RLQULlST-CRLATLfT)  appears  in  a.  Assume  for  the  sake  of  deriving  a  contradiction  that  T  is 
a  pending  access  in  a|X.  Then  I  emma  22  implies  that  T  is  live  in  a.  Also.  I  .emma  17  implies  that 
parcntfl)  is  live  in  a.  Then  Lemma  23  implies  that  one  of  T  or  parcnt(T)  is  an  ancestor  of  the 
other;  since  T  and  T  arc  both  leaves  of  the  transaction  tree,  the  only  possibility  is  that  parcntfl’)  is 
a  proper  ancestor  of 'I”.  I  .ct  T’  be  the  sibling  of  T  which  is  an  ancestor  of  T.  linen  T*  is  live  in  a. 
by  Lemma  18.  That  is,  there  is  a  CRLATLfT*).  but  no  COMMI  T  for  T*  in  a.  But  this 
contradicts  the  scheduler  preconditions  for  w.  ITtcrcforc.  there  is  no  pending  access  in  a|X.  I 

3.6.4.  Visibility  and  Serial  Schedules 

In  this  paragraph,  we  prove  interesting  lemmas  about  visibility  in  serial  schedules. 

I  emma  25: 1  .ct  a  be  a  serial  schedule,  and  m  an  operation  in  a.  Ihcn  transaction^ )  is  visible  in 
a  to  some  transaction  which  is  live  in  a. 

Proof:  I  .ct  1’  =  transaction^ ).  Since  a  is  not  empty.  T0  is  live  in  a.  let  T  be  the  least  ancestor 
of  T  which  is  live  in  a.  Ihc  proof  is  by  induction  on  the  distance  from  T  to  T.  If  T  =  1”.  the 
result  is  trivial.  So  assume  that  T  *  T.  Ihcn  COMMITf T)  is  in  o.  and  so  T  is  visible  to  parentfT) 
in  a.  lemma  13  implies  that  a  contains  a  RLQULST— CRLATLfT)  operation,  which  occurs  at 
parentfT).  Ihcn  the  inductive  hypothesis  implies  that  parcntfl’)  is  visible  to  1".  Ihcn  T  is  visible 
to  T  by  lemma  8.  I 

lemma  26: 

1.  let  a  be  a  serial  schedule.  1’  a  transaction  and  X  an  object.  Ihcn  visiblcfa.l’XX  is  a  prefix 
of  a|X. 

2.  let  a  be  a  serial  schedule,  T  a  transaction  and  P  a  primitive.  Ihcn  visiblcfa.T)|P  is  a  prefix 
of«|P. 

Proof:  1.  Let  it  and  9  be  operations  in  a|X.  with  *  preceding  9.  and  9  an  operation  in 
visiblcfa.T).  Let  a’  be  the  prefix  of  a  preceding  9.  let  1"  =  transactionf9)  and  T*  = 
transaction^).  Since  9  is  either  a  CRHAl’K  or  a  RKQUHST- COMMIT  forT,  well-formedness 


of  a  implies  that  T  is  live  in  a'<p.  Thus,  by  l  .cmma  23,  the  only  live  transactions  in  a'f  arc 
ancestors  of  T.  Hy  I  emmu  25,  T’  is  visible  to  an  ancestor  of  I"  in  a'«p.  and  hence  in  a.  By 
l  .cmma  8.  T’  is  visible  to  T  in  a.  But  T  is  visible  to  T  in  a,  by  assumption,  l  .cmma  8  then 
implies  that  T"  is  visible  to  T  in  a,  which  gives  the  rcsulL 

2.  Immediate  from  l.cmma  11  and  part  1.  I 

larniina  27:  l.ct  a  be  a  nonempty  serial  schedule.  I.et  w  be  the  last  operation  in  a  which  is  an 
output  of  the  serial  scheduler.  Then  transaction! ir)  sees  everything  in  a. 

Proof:  l  .ct  I  =  transaction! w).  We  first  show  that  T  is  live  in  a.  Hither  n  is  a  CRKATKfT)  or 
else  it  is  a  return  operation  for  a  child  T  of  T.  In  tlic  latter  ease,  l.cmma  14  implies  that 
CRKATH(T)  also  occurs  in  a.  Ihus,  in  either  case,  CRKATHfl’)  occurs  in  a.  Now,  if  a  return 
operation  for  T  occurs  in  a,  l.cmma  21  implies  that  it  follows  w,  which  is  impossible.  Ihus,  no 
return  operation  for  I'  occurs  in  a.  It  follows  thatT  is  live  in  a. 

Then  l,cmma  23  implies  that  the  only  other  transactions  that  arc  live  in  a  must  be  ancestors  or 
descendants  of  T.  We  claim  that  no  proper  descendants  of  T  arc  live  in  a.  So  assume  for  the  sake 
of  obtaining  a  contradiction  that  U  is  a  proper  descendant  of  T  which  is  live  in  a.  then  U  is  a 
descendant  of  a  child  V  off,  and  V  is  live  in  a,  by  Lemma  18.  Let  a'  be  the  prefix  of  a  preceding 
w.  There  arc  three  eases. 

(1) t  is  CRKATKfT). 

Then  Lemma  14  yields  a  contradiction. 

(2)  *  is  a  COMMIT  operation  for  T.  a  child  of T. 

'Ihcn  T  *  V.  since  T  is  not  live  in  <*.  But  T  and  V  arc  both  live  in  a’,  which  contradicts  Ixmma 
23. 

(3)  v  is  an  ABORT(T),  for  child  T  of  T. 

Ihcn  T  *  V,  since  T  is  not  live  in  a.  But  V  is  live  in  a.  But  then  the  scheduler  preconditions  for 
w  arc  not  satisfied,  a  contradiction. 

Ihus,  no  descendants  arc  live  in  a.  so  the  only  transactions  that  arc  live  in  a  arc  ancestors  of 
T.  Now  let  <p  be  any  operation  in  a.  Lemma  25  implies  that  transaction! <p)  is  visible  in  a  to  some 
ancestor  of  T,  and  hence  to  T.  I 

l/cmma  28:  I.ct  a  be  a  serial  schedule,  and  T  a  transaction.  Ihcn  visiblc(a.T)  is  a  serial 
schedule. 

Proof:  We  proceed  by  induction  on  the  length  of  a.  ’Ihc  basis,  length  0.  is  trivial.  Let  a  =  a’w, 
where  v  is  a  single  operation.  Fix  transaction  T.  and  let  1"  =  transaction! ir).  If  1"  is  not  visible  to 
T  in  a.  then  visiblc(a,T)  =  visiblc(a\T),  and  the  result  is  true  by  inductive  hypothesis.  So  assume 
that  T  is  visible  to  T  in  a. 

If  v  is  an  output  operation  of  a  primitive  P.  then  visiblc(a,T)|P  is  a  prefix  of  a|P,  by  Ixmma  26, 
and  thus  is  a  schedule  of  P.  By  the  inductive  hypothesis,  visible! a’.T)  is  a  serial  schedule.  Also, 
visible!**,’!')  =  visible!**’,'!')*  by  Lemma  12.  Ihcn  Lemma  4  shows  that  visible! <*,T)  is  a  serial 
schedule. 

On  the  other  hand,  if  ir  is  an  output  operation  of  the  scheduler,  then  Lemma  27  implies  that  T 
sees  everything  in  a.  But  since  T  is  visible  to  T  in  a.  it  follows  that  T  sees  everything  in  a.  Ihus, 
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visiblcfa.T)  =  a.  a  serial  schedule.  I 

3.6.5.  Reordering  and  Combining  Serial  Schedules 

In  this  paragraph,  we  describe  ways  in  which  serial  schedules  can  be  modified  and  combined  to  yield  other 
serial  schedules.  These  lemmas  arc  used  in  the  proof  of  the  main  theorem,  in  Section  7. 

Lemma  29:  Let  a  and  a  be  two  equivalent  serial  schedules.  If/?  is  a  sequence  of  serial 
operations  such  that  nfi  is  a  serial  schedule,  then  a'/ 3  is  a  serial  schedule,  and  is  equivalent  to  a/L 

Proof:  Lquivalcncc  is  trivial.  The  fact  that  afi  is  a  serial  schedule  follows  because  the 
preconditions  of  the  serial  scheduler  depend  only  upon  the  presence  of  previous  operations,  not 
their  order.  I 

The  next  lemma  says  that  any  serial  schedule  can  be  transformed  by  moving  all  the  operations  visible  to  any 
particular  transaction  to  the  beginning  of  the  schedule,  and  the  result  is  another  serial  schedule.  This  lemma 
can  be  thought  of  as  describing  a  kind  of  "canonical  form”  for  a  serial  schedule,  with  respect  to  a  particular 
transaction. 

Ixwinui  30:  I  .ct  a  be  a  serial  schedule,  and  T  any  transaction.  I.et  >9  =  visiblcfa.T’).  Then  /?(a  - 
/?)  is  equivalent  to  a  and  is  serial. 

Proof:  I  .ct  a'  =  fi(a  -  ft).  If  P  is  any  primitive,  then  Lemma  26  implies  that  /?|P  is  a  prefix  of 
a|P.  Thus,  a  is  equivalent  to  a. 

To  show  that  a'  is  serial,  we  proceed  by  induction  on  its  prefixes.  By  Lemma  28,  fl  is  serial,  so 
we  can  use  / 3  as  the  basis.  I  .ct  yv  be  a  prefix  of  a\  where  v  is  a  serial  operation  in  a  -  /?  and  y  is  a 
serial  schedule.  If  m  is  an  output  operation  of  a  primitive  P,  then  ytt|P  is  a  prefix  of  n’|P,  =  a|P 
by  equivalence,  which  is  a  schedule  of  P.  Then  Lemma  4  shows  that  yv  is  a  serial  schedule.  So 
assume  that  v  is  an  output  operation  of  the  serial  scheduler. 

Let  s  be  the  state  of  the  serial  scheduler  after  y.  1  .ct  y'n  be  the  prefix  of  a  ending  in  tr,  and  let  s’ 
be  the  state  of  the  serial  scheduler  after  y\  Then  w  is  enabled  in  s’.  We  must  show  that  w  is 
enabled  in  s.  'litis  suffices,  by  Ixmma  4. 

Since  every  operation  in  y’  is  also  in  y,  it  follows  that  each  component  set  of  s’  is  a  subset  of  the 
corresponding  set  of  s.  There  arc  three  eases. 

( 1 )  w  is  CRKATKO”)  for  some  transaction  T. 

Then  transaction!*)  =  T,  and  T  is  not  visible  to  T  in  a.  Then  1”  €  create  -  rcqucstcd(s’)  C 
create  -  requested! s).  Also,  it  is  easy  to  show  that  I"  $  crcatcd(s).  Now  let  U  be  in  siblingsfT)  fl 
crcatcd(s).  If  U  €  crcatcd(s’),  then  U  €  rcturncd(s’)  since  w  is  enabled  in  s’.  C  returncd(s),  as 
needed.  So  suppose  that  U  €  crcatcd(s’).  'ITien  CRHATH(U)  occurs  in  fl,  so  U  is  visible  to  1’  in  a. 

Since  a  contains  both  CRKATKCn  and  CRKATKfU).  Lemma  23  implies  that  a  must  contain  a 
COMMI  T  for  at  least  one  of  T  or  U.  If  a  contains  a  COMMI  T  for  U.  then  it  occurs  in  so  U  € 
rcturncd(s).  On  the  other  hand,  if  a  contains  a  COMMI  T  for  I”,  then  T  is  visible  to  U  in  a,  so 
Lemma  8  implies  that  T  is  visible  to  T  in  a.  a  contradiction. 

(2)  n  is  COMMITCr.v)  for  some  transaction  T  and  value  v. 
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I'hcn  transaction!*)  is  pareiu(T).  which  is  not  visible  to  'I’  in  a.  I'hcn  (T.v)  is  in 
commit- requcsled(s’)  C  commit- requcsted(s).  Also,  it  is  easy  to  show  that  T  is  not  in 
rcturned(s).  Now  let  U  he  in  children!  I")  IT  create- rcqucstcd(s).  Then  there  is  a 
RIQULST-CRI-ATLXU)  in  y.  I  bis  RHQUI-SI  -CRI-A I  IXU)  occurs  at  T.  which  cannot  be 
visible  to  T  in  a  since  parent!  T)  is  not  visible  to  T  in  a.  Thus,  the  RLQULiST-CKLA'ITXU) 
docs  not  occur  in  /3.  so  it  occurs  in  y\  Since  w  is  enabled  in  s',  we  have  U  €  rctumed(s')  C 
rcturncd!s). 

(3)  w  is  AHORTCD  for  some  transaction  T. 

Then  transaction!*)  =  parcntCr).  and  parcntfl")  is  not  visible  to  T  in  a.  I'hcn  T  € 
create- rcqucstcd(s')  C  create -rcqucsted(s).  Also,  it  is  easy  to  show  that  T  C  crcatcd(s).  Now 
let  ll  €  siblings! T)  H  crcatcd!s).  I'hcn  CRKA'ITXU)  occurs  in  y.  But  CRLATLXU)  occurs  at  U, 
and  U  cannot  be  visible  to  T  in  a  since  parent! U)  =  parent!  I”)  is  not  visible  to  T  in  a.  I'hcrcforc. 
CRI*'ATI;XU)  docs  not  (tccur  in  p,  so  it  occurs  in  y*.  Then  U  is  in  siblings!’!")  fl  crcatcd!s’)  Q 
rcturncd(s')  C  rcturncd(s).  I 


Ihc  following  lemma  is  an  easy  consequence  of  the  preceding  one. 

I  einnia  31 :  l  et  a  be  a  schedule  of  serial  operations,  and  let  T  and  I"  be  two  transactions  with  T 
visible  to  T  in  a.  I  et  p  and  /?'  be  serial  schedules,  such  that  fi  is  equivalent  to  visible! a.T)  and  /T 
is  equivalent  to  visibkKa.T).  Then  P"  =  p\p  -  /3‘)  is  equivalent  to  P  and  serial. 

Proof:  I  .ct  y  =  visible!/?,  !").  I'hcn  y  is  serial  by  I  .emma  28.  lemma  30  implies  that  y(/?  -  y)  is 
equivalent  to  P  and  serial.  Lemma  10  implies  that  /?'  is  equivalent  to  y.  and  thus  that  P  -  y  =  P  - 
P'.  Then  Lemma  29  implies  that  p"  is  equivalent  to  y !/?  -  y)  and  serial.  Thus.  P"  is  equivalent  to 
P  and  serial.  I 


The  next  two  lemmas  arc  used  in  the  proof  of 'I’hcorcm  68.  Kach  describes  a  way  of  "cutting  and  pasting” 

two  serial  schedules  to  yield  a  new  serial  schedule. 

Ivcmma  32:  Let  a/^COMMITfT.u)  and  aP2  be  two  serial  schedules  and  T.  T  and  T”  three 
transactions  such  that  the  following  conditions  hold: 

( 1 )  T  is  a  child  of  T’  and  T  is  a  descendant  of  T*  but  not  of  T. 

(2)  T  secs  everything  in  apv 

(3)  T  secs  everything  in  aPY 

(4)  a  =  visiblcfa/lj.T’)  =  visible!  a/3  2,T’)  and 

(3)  no  basic  object  has  operations  in  both  Pt  and  P2- 
Then  a/3,  COM  MIT!  r,u)^2  is  a  serial  schedule. 

Proof:  Note  first  that  if  T  =  T”,  then  p2  is  empty  and  the  result  is  trivial.  So  assume  that  T  * 

T*.  'I'hcn  T  is  a  descendant  of  a  child  U  ofT”,  and  U  *  T. 

Any  operation  in  a/3,  whose  transaction  is  not  a  descendant  ofT,  must  be  in  visible! a/9 ^T*)  by 
Lemma  8.  Similarly,  any  operation  in  aP2  whose  transaction  is  not  a  descendant  of  U.  must  be  in 
visiblc!a/?2, T').  Ilius,  /9,  and  P2  contain  only  operations  at  descendants  of  T  and  U.  respectively. 
Since  T  and  U  arc  distinct  siblings,  and  by  assumption  no  objects  have  operations  in  both  /3,  and 
P2 ,  it  follows  that  no  primitive  has  an  operation  occurring  in  both  /3t  and  P2. 

We  proceed  by  induction  on  prefixes  of  a/3,COMMIT(T.u)/32.  Let  a’qp  be  a  prefix  of 
a^COMMITCr.u)^,  with  a’  a  serial  schedule  and  <p  a  serial  operation.  We  use  a  ip  = 
aljCOMMNXT.u)  as  the  basis,  since  aP .COMM I  lf  P.u)  is  a  serial  schedule  by  assumption.  So 


assume  lhat  a  =  a/9  |C0MMIT(T,u)/9'  for  some  sequence  /9\  There  arc  two  eases,  depending 
on  whether  9  is  an  output  of  a  primitive  or  of  the  serial  scheduler. 

Suppose  dial  <p  is  an  output  operation  of  a  primitive  P.  Then  ^COMMIKT.v)  contains  no 
operations  at  P.  Thus,  nc'qpjl*  =  «/3'<jp|P.  which  is  a  prefix  of  a/9-JP.  which  is  a  schedule  of  P  since 
afl2 's  a  serial  schedule.  Thus.  a'<p|P  is  a  schedule  of  P.  The  result  follows  by  I  .emma  4. 

So  suppose  <p  is  an  output  of  die  serial  scheduler.  Ilicn  transaction^)  =  V  for  some 
descendant  V  of  U.  I  .ct  s  be  die  suite  of  the  serial  .scheduler  after  a',  and  let  s'  be  die  state  of  the 
serial  scheduler  after  a/9'.  Then  the  following  relationships  hold  between  s  and  s'. 

1.  V  €  create-  rcqucstcd( s')  *  crcatcd(s')  iff  V  €  create-  rcqucstcd(s)  -  crcatcd(s) 

2.  childrcn(V)  D  create -rcqucstcd(  s’)  C  rctumcd(s')  iff  childrcn(V)  fl  create  -  requestedfs) 

C  rctumcd(s) 

3.  (V.v)  €  commit-  rcqucstcd(s')  iff  (V.v)  €  commit-  rcqucstcd(s) 

4.  V  4  rctumcd(s')  iff  V  <  rctumcd(s) 

5.  siblings(V)  (T  crcatcd(s')  C  rctumcd(s')  iff siblingsf V)  H  crcatcd(s)  C  rcturncd(s) 

Since  the  operations  in  /9(  arc  all  at  descendants  of  T,  and  those  of  arc  all  at  descendants  of 
U.  the  first  four  biconditionais  arc  immediate  from  Lemma  7.  If  V  is  a  proper  descendant  of  U. 
the  last  biconditional  also  follows.  It  remains  to  show  that  siblings(U)  D  crcatcd(s')  C  rctumcd(s') 
iff  siblings(U)  D  crcatcdfs)  C  rctumcd(s).  But  any  sibling  of  U  created  in  a/9’  is  created  in  a, 
and  the  only  sibling  of  U  created  in  a  and  not  a/9‘  is  T.  and  T  €  rctumcd(s).  Ihus.  the  claims 
arc  true. 

Since  9  is  enabled  in  s',  the  claims  above  imply  that  ?  is  also  enabled  in  s.  The  result  follows.  I 

lemma  33:  Let  aADORT(T)  and  a/9  be  two  serial  schedules,  and  let  T.  T*  and  T"  be 
transactions,  such  that  the  following  conditions  hold: 

( 1)  T"  is  a  child  of  T”  and  T  is  a  descendant  of  T”  but  not  of  T, 

(2)  T  sees  everything  in  afi,  and 

(3)  a  =  visiblcfa.T")  =  visiblc(a/9.T"). 

Ihcn  aABORT(T)^  is  a  serial  schedule. 

Proof:  Similar  to,  but  somewhat  simpler  than,  the  proof  of  Lemma  32.  I 

4.  Resilient  Objects 

Having  stated  our  correctness  conditions,  we  arc  now  ready  to  begin  describing  implementations  and 
proving  that  they  meet  the  requirements.  'Ihis  section  and  the  next  arc  devoted  to  the  description  of  a 
concurrent  system  which  permits  the  abort  of  transactions  that  have  performed  steps.  An  important 
component  of  a  concurrent  system  is  a  new  kind  of  object  called  a  "resilient  object"  which  we  introduce  in 
this  section.  A  resilient  object  is  similar  to  a  basic  object  but  it  has  the  additional  capability  to  undo 
operations  of  transactions  that  it  discovers  have  aborted. 
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Resilient  objects  have  no  capabilities  for  managing  concurrency:  rather,  they  assume  that  concurrency 
control  is  handled  externally  (by  lock  manager  components  of  the  scheduler).  Ihis  section  defines  resilient 
objects  and  presents  some  of  their  properties.  It  also  digresses  slightly  from  the  main  development  by 
describing  and  proving  correct  a  particular  implementation  of  resilient  objects,  which  arc  constructed  by 
keeping  multiple  copies  of  corresponding  basic  objects.  The  resilient  object  manages  these  copies  as  versions 
of  the  data  object.  Upon  learning  of  an  abort,  the  appropriate  stored  version  is  used  in  place  of  the  current 
version. 

4.1.  Definitions 

Resilient  object  R(X)  mimics  the  behavior  of  basic  object  X,  but  has  two  additional  input  operations. 
INFORM -COMMIT- AT(X)OF<T)  and  INFORM  — ABORT— AT(X)OF(T).  for  every  transaction 
T.  Upon  receiving  an  INFORM- ABORT- AT(X)OF(T).  R(X)  erases  any  effects  of  accesses  which  arc 
descendants  of  T.  'fhis  property  is  made  formal  as  the  "Resiliency  Condition"  below. 


R(X)  has  the  following  operations,  which  we  call  R(Xf operations. 

Input  Operations: 

CRFATFX’I  ).  T  an  access  to  X 
I N  FOR  M  -  COM  M I  I  -  AT(X)OF(T) 

INFORM  -  ABORT-  AT(X)OF(T) 


Output  Operations: 

RKQUFST— COMMIT(T,v),  Tan  access  to  X 


In  order  to  describe  well-formedness  for  resilient  objects,  we  require  a  technical  definition  for  the  set  of 
transactions  which  arc  active  after  a  sequence  of  R(X)-opc rations.  Roughly  speaking,  the  transactions  which 
arc  active  arc  those  on  whose  behalf  the  object  has  carried  out  some  activity,  but  whose  fate  the  object  docs 
not  know. 

The  definition  is  recursive  on  the  length  of  the  sequence  of  R(X)  operations.  Namely,  only  T0  is  active  after 
the  empty  sequence.  I^et  a  =  /?tr.  when:  w  is  a  single  operation,  and  let  A  and  B  denote  the  sets  of  active 
transactions  after  a  and  /?,  respectively.  If  w  is  CRKATFXT).  then  A  =  B  U  {T}.  If  «  is  a 
RKQUHST-COMMIT  for  T,  then  A  =  B.  If  w  is  INFORM -COMMIT-  AT(X)OF(T),  and  if  T  is  in  B. 
then  A  =  (B  -  {T})  U  {parcnt(T)};  ifT  is  not  in  B,  then  A  =  B.  If  w  is  INFORM- ABORT-  AT(X)OF(T). 
then  A  =  B  -  dcsccndantsfl’). 

Now  we  define  well-formedness  for  sequences  of  R(X)  operations.  Again,  the  definition  is  recursive. 
Namely,  the  empty  schedule  is  well-formed.  Also,  if  a  =  a  w  is  a  sequence  of  R(X)-opcrations,  then  a  is 


well-formed  provided  that  a*  is  well-formed,  and  the  following  hold. 

•  Ifw  is CRHATHf I*),  then 

(i)  there  is  no  CRI%ATI-(T)  in  a\ 

(ii)  all  the  transactions  which  are  active  after  a  arc  ancestors  off. 

•  Ifw  is  a  RKQUFST -COMMI  T  for  I',  then 

(i)  there  is  no  RKQUKSI'— COMMIT  forT  in  a,  and 

(ii)  T  is  active  alter  a. 

•  Ifw  is  INFORM-COMMIT- AT(X)OF(T).  then 

(i)  there  is  no  INFORM  -  ABORT-  AT(X)OF(T)  in  o’,  and 

(ii)  ifT  is  an  access  to  X.  then  a  RKQUFST— COMMIT  forToccurs  in  o’. 

•  Ifw  is  INFORM  — ABORT— AT(X)OF(T),  then 

(i)  there  is  no  INFORM -COMMIT— AT(X)OF(T)  in  o’. 

An  immediate  consequence  of  these  definitions  is  that  the  transactions  active  after  any  well-formed 
sequence  of  R(X)-opcrations  a  arc  a  subset  of  the  ancestors  of  a  single  active  transaction,  which  we  denote 
lcast(a). 

For  a  a  sequence  of  R(X)-opcrations.  define  undofa)  recursively  as  follows.  Define  undo(X)  =  X,  where  X 
is  the  empty  sequence.  Ixt  a  =  /9w.  where  w  is  a  single  operation.  If  w  is  a  serial  operation  (a  CRKATK  or  a 
R HQU HST -  COM  M  IT),  then  undo(a)  =  undo(0)w.  If  w  is  INFORM  -  COMMIT-  AT(X)OF(T),  then 
undo(a)  =  undo(/9).  If  w  is  INFORM -ABOR T-A'l’(X)OF(T).  then  undo(a)  is  the  result  of  eliminating, 
from  undo(/J),  all  operations  whose  transactions  arc  descendants  of  rl’.  Note  that  undo(a)  contains  only  serial 
operations. 

let  a  be  any  sequence  of  R(X)-opcrations,  and  let  w  be  an  operation  in  a  of  the  form 
INFORM- ABORT— AT(X)OF(T).  I’hcn  the  scope  of  w  in  a  is  the  subsequence  y  of  a  consisting  of 
operations  eliminated  by  w. 

Resiliency  Condition 

Resilient  object  R(X)  satisfies  the  resiliency  condition  if  for  every  well-formed  schedule  a  of  R(X),  undo(a)  is 
a  schedule  of  basic  object  X. 

We  require  that  resilient  object  R(X)  preserve  well-formedness  and  satisfy  the  resiliency  condition. 

The  resiliency  condition  is  the  correctness  condition  required  by  the  concurrent  schedulers  at  the  object 
interface.  The  well-formedness  requirement  is  a  syntactic  restriction,  and  the  condition  that  undo(a)  be  a 
schedule  of  basic  object  X  expresses  the  required  semantic  relationship  between  the  resilient  object  and  the 


basic  object  it  incorporates.  Ihc  important  property  which  must  be  preserved  is  that  the  correctness  condition 
at  the  resilient  objects,  together  with  the  behavior  of  the  concurrent  scheduler,  assures  correctness  at  the 
transaction  boundaries. 


4.2. 1‘roperties  of  Resilient  Objects 

This  subsection  contains  a  collection  of  simple  lemmas  about  the  properties  of  well-formed  sequences  of 
K(X)  operations. 

l/cmnui  34:  l  et  aw  be  a  well-formed  sequence  of  K(X)  operations,  with  w  a  single  operation. 

The  following  arc  true. 

1.  If  *  is  a  serial  operation,  then  transaction!  w)  is  active  after  aw. 

2.  IfT  is  an  access  active  after  a  prefix  of  a  but  not  after  a,  then  T  is  not  active  after  aw. 

3.  If  w  is  a  RKQUKST-COMMIT  forT,  then  CRKATKfO  is  the  last  serial  operation  in  a. 

Proof: 

1.  Immediate  from  the  definition  of  active  and  well-formedness. 

2.  because  T  has  no  descendants,  it  can  only  become  active  when  a  CRKATKfO  operation 
occurs,  which  can  only  happen  once  in  a  well-formed  schedule. 

3.  Suppose  the  last  serial  operation  in  a  is  qp.  with  qp  *  CRKATKfO-  l  et  transaction!  9)  = 

T.  By  well-formedness,  T  *  T.  Also  by  well-formedness.  T  is  active  in  o.  so  that 
CRKATKfO  must  occur  in  a.  and  so  precedes  9.  By  part  (1),  T  is  active  following 
CRKATKfO  and  after  w,  and  T  is  active  following  9.  But  1'  cannot  be  active  when  9 
occurs,  by  well-formedness,  contradicting  part  (2)  of  this  lemma. 

I 

lemma  35:  l.ct  a  be  a  well-formed  sequence  of  R(X)  operations,  let  Tand  1”  be  accesses  to  X. 
with  T  *  T,  and  let  w  and  9  be  serial  operations  with  transactions  1’  and  1".  respectively.  If  w 
precedes  qp  in  a.  then  between  w  and  qp.  there  is  either  an  INFORM  — ABORT— AT(X)  for  some 
ancestor  of  T.  or  else  there  arc  INFORM  -COMMIT- AT(X)OK(U)  operations  for  all  ancestors 
U  of  T  which  arc  not  ancestors  of  T,  occurring  in  order  from  lowest  to  highest  in  the  transaction 
tree  ordering. 

Proof:  By  part  3  of  lemma  34  and  well-formedness,  we  may  assume  that  qp  =  CRKATKfT). 
Lemma  34  implies  that  T  is  active  immediately  after  w.  By  well-formedness,  before  CRKATKfT) 
can  occur,  it  must  be  that  all  transactions  which  arc  active  arc  ancestors  of  T.  There  arc  only  two 
ways  in  which  this  can  happen.  One  possibility  is  that  R(X)  first  receives  INFORM  —  COMM  ITS 
for  all  ancestors  of  T  up  to  leaf  I'.'T),  in  order  from  lowest  to  highest  in  the  transaction  tree 
ordering.  The  other  possibility  is  that  R(X)  first  receives  an  INFORM -ABORT  for  an  ancestor 
of  T.  I 

lemma  36:  Let  aw  be  a  well-formed  sequence  of  R(X)  operations,  with  w  = 
INFORM  -  ABOR  T-  AT(X)OFf  1).  13100  undofaw)  is  a  prefix  of  undo(a). 

Proof:  Suppose  not.  'Ilicn  there  is  a  subsequence  qp ^  of  two  operations  in  undo(a),  such  that  4* 
is  in  undofaw)  and  qp  is  not.  Clearly,  qp  and  41  arc  serial  operations,  transaction(qp)  is  a  descendant 


28 


of  I'  and  transaction^)  is  not.  Since  <p  is  not  in  the  scope  of  an  INFORM- AMORT  in  a.  ny 
l  emma  35.  there  is  an  INFORM -COMMI  T  between  9  and  lor  every  proper  descendant  of 
lca(iransaclion(qp).iransaclion(t/'))  that  is  an  ancestor  of  transaction^),  including  T.  This 
contradicts  the  well-formedness  of  aw.  I 

Lemma  37:  Let  a  be  a  well-formed  sequence  of  R(X)  operations,  and  let  I  be  any  transaction 
active  in  a.  other  than  l'0.  Then  undo(u)  contains  an  operation  q>  at  a  descendant  T  of  T.  which  is 
followed  in  a  by  an  INFORM -COMMI  T  for  every  ancestor  of  T'  which  is  a  proper  descendant 
off. 

Proof:  The  proof  is  by  induction  on  a,  with  a  trivial  basis.  I  .cl  a  =  a'w.  such  that  the  lemma  is 
true  for  a'  and  that  w  is  a  single  operation.  !.ct  T  be  a  transaction  active  after  a.  There  arc  four 


Suppose  w  is  CRKATKfT).  Then  undo(a)  =  undofa’)w.  If T  *  T\  the  result  is  immediate  by 
the  induction  hypothesis,  since  T  is  active  aflcr  a*.  If T  =  T\  then  the  lemma  follows,  with  w  = 


If  w  is  a  RI-QUKS' T-COMMIT  for  a  transaction  T*.  then  undo(a)  =  undofa*)w  and  the  same 
transactions  arc  active  in  a  and  a’.  The  result  is  immediate. 

Suppose  w  is  an  INFORM  -COMMI  T  for  a  transaction  'I"’.  Then  undo(a)  =  undofa’)w.  If  T 
is  active  aflcr  a\  the  result  is  immediate.  If  T  is  not  active  aflcr  a\  it  follows  that  T  =  parcntfT'). 
The  result  is  immediate  from  the  induction  hypothesis. 


Suppose  w  is  an  INFORM  -  AMORT  for  a  transaction  U.  Since  T  is  active  aflcr  a.  it  was  active 
aflcr  a'  and  U  is  not  an  ancestor  of  T.  Let  qp  be  the  transaction  of  transaction  T  which  follows 
from  the  inductive  hypothesis  applied  to  T  and  o’.  Since  a  is  well-formed  and  o’  contains 
INFORM  -COMMITS  for  every  ancestor  of  I"  up  to  T,  U  is  not  an  ancestor  ofT.  It  follows  that 
<p  is  in  undo(a)  and  the  result  holds.  I 

lamina  38:  Let  a  be  a  well-formed  sequence  of  R(X)  operations,  and  let  leastfa)  =  T.  If 
undo(a)  is  nonempty,  then  it  ends  in  an  operation  of  a  descendant  ofT. 

Proof:  If  T  =  T0.  the  result  is  trivial,  so  assume  otherwise.  My  the  previous  lemma,  undo(a) 
contains  an  operation  qp  at  a  descendant  ofT.  Without  loss  of  generality,  assume  that  qp  is  the  last 
operation  in  undofa)  at  a  descendant  ofT.  If  any  other  operation  w  followed  qp  in  undo(a).  by 
Lemma  35  a  would  contain  INFORM -COMMI  TS  for  every  ancestor  of  transaction^)  up  to 
IcaftransactionfqO.transactionfw)),  which  includes  T.  I'hcn  T  is  not  active  in  a.  a  contradiction.  I 

lx?mma  39:  Let  aw  be  a  well-formed  sequence  of  R(X)  operations,  with  w  = 
INFORM  -  AMOR  T-  AT(X)OF(T).  If  T  is  not  an  ancestor  of  leastfa).  then  undofaw)  = 
undofa). 

Proof:  Suppose  that  T  is  not  an  ancestor  of  leastfa)  and  that  undofaw)  *  undofa).  Then 
undofa)  contains  a  serial  operation  qp  at  a  descendant  1”  of  T.  My  Lemma  38.  <p  is  followed  in 
undofa)  by  an  operation  at  a  descendant  of  leastfa).  My  Lemma  35,  a  contains  an 
INFORM -COMMIT  for  every  ancestor  leastfa)  up  to  leaf  leastfa),!").  which  includes  T. 
contradicting  the  well-formedness  of  aw. 


We  arc  now  able  to  show  that  the  undo  operator  preserves  well-formedness. 

liCmma  40:  If  a  is  a  well-formed  sequence  of  R(X)-opcrations.  then  undofa)  is  a  well-formed 
sequence  of  X-opcrations. 
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Proof:  The  proof  is  by  induction  on  the  length  of  a.  The  basis  is  trivial.  Assume  a  =  a'w, 
where  v  is  a  single  operation,  and  undo(<T)  is  a  well- formed  sequence  of  X-operations.  If  ir  is  an 
INIORM-ABORT  or  INKORM  -COMMIT.  undo(a)  is  a  prefix  of  undo(a').  by  Lemma  36,  and 
the  result  is  immediate. 

If  w  is  CRKATKXT),  then  undo(a)  =  undo(a')ir.  By  the  well-formedness  of  a,  CRKATKXT) 
docs  not  appear  in  a\  and  so  not  in  undo(a').  lienee,  (i)  is  satisfied.  To  see  (ii).  assume  that 
CRKATKXT)  occurs  in  undo(a').  for  access  T.  Ihcn  lemma  35  implies  that 
INKORM -COMMIT- AT(X)OK(T)  occurs  after  CRKATKXT)  in  a.  Ihcn  well-formedness 
(the  precondition  for  INFORM— COMMIT- AI(X)OKXT))  implies  that  a 
RKQUKST -COM  MIT  for  T  occurs  in  a.  and  well-formedness  also  implies  that  the 
RLQUKST— COMMIT  for  T  follows  the  CRI-A  ITXD.  therefore,  the  RKQUKST- COM  MIT 
occurs  in  undofa').  and  so  T  is  not  pending  in  undo(a').  thus,  (ii)  is  satisfied. 

If  *  is  a  RKQUKST -COM  MIT  for  T.  then  again  undo(a)  =  undo(a')w.  and  by  the  well- 
formedness  of  a,  (i)  no  RKQUKST -COM  MIT  for  T  appears  in  a\  and  so  not  in  undo(o'),  and 
(ii)  T  is  active  after  a\  and  it  follows  that  CRKATKXT)  occurs  in  undo(a').  I 

4  J.  Construction  of  i  Resilient  Object 

In  this  subsection,  we  describe  a  construction  of  a  resilient  object  R(X)  from  a  basic  object  X. 

Recall  that  a  resilient  object  X  is  distinguished  from  a  basic  object  in  that  it  has  INKORM-  ABOR  T  and 
I N  KOR  M- COM  MIT  operations,  a  different  definition  of  well-formedness,  and  satisfies  the  resiliency 
condition.  The  resilient  object  R(X)  is  constructed  from  the  states,  transition  function  and  operation  labels  of 
the  basic  object  X.  Ihe  resilient  object  R(X)  maintains  a  collection  of  "copies  of  X"  (i.c.  remembers  states  of 
X).  one  for  each  active  transaction,  with  a  particular  current  copy  (corresponding  to  the  least  active 
transaction)  to  which  CRKATK  operations  are  sent  When  R(X)  receives  an  INFORM  — ABORT,  the 
appropriate  stored  copy  becomes  the  current  copy,  thereby  erasing  the  effects  of  the  operations  in  the  scope  of 
the  INKORM -ABORT. 


Ihe  state  of  R(X)  consists  of  a  pair  (act. map),  where  act  is  a  set  of  "active”  transactions,  and  map  is  a 
function  from  act  to  states  of  basic  object  X.  In  the  well-formed  executions  of  R(X)  (defined  below),  act  will 
always  be  a  subset  of  the  set  of  ancestors  of  one  particular  transaction  in  act,  called  lcast(act).  (In  ease  act  has 
no  least  member  (which,  again,  will  not  arise  in  executions  with  well-formed  schedules),  define  lcast(act) 
arbitrarily.)  Ihe  copy  for  )cast(act)  is  considered  to  be  current  'Ihe  initial  states  of  R(X)  arc  those  in  which 
act  =  {T0}  and  mapfl^)  is  an  initial  state  of  the  basic  object  X.  In  the  following  specification  of  the 
operations  of  R(X),  let  (act'.map’)  be  the  state  of  R(X)  prior  to  the  operation,  and  (actmap)  be  the  state  of 
R(X)  after  the  operation. 

•  CRKATKXT),  T  an  access  to  X: 

Postcondition: 
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act  =  act'  U  { T} 

map(U)  =  map'(U)  for  all  U  €  act*  {T} 

mapC  I  )  =  s.  where  (map’(lcusl(uct')),CRKATF(T).s)  is  in  the  transition  relation  of  X 

•  INFORM- ABORT- AT(X)OF(T): 

Postcondition: 

act  =  act*  -  {descendantsO')} 
map(U)  =  map'(U)  for  all  U  €  act 

•  INFORM -COM  M  IT- AT(X)OF(T): 

Postcondition: 

if  T  €  act*  then 
begin 

act  =  (act’  -  {T})  U  {parcnt(T)} 

map(U)  =  map’(U)  for  U  €  act  -  {parentfi')} 

map(parcnt( T))  =  map’('0 

end 

If  T  £  act'  then  act  =  act'  and  map  -  map' 

•  R  KQU  KST  -  COM  M  IT(T,v): 

Precondition: 

lcast(act*)  =  T 

(map'(T).RF.QUHST-COMMIT(T,v),s)  is  in  die  transition  relation  of  X 

Postcondition: 

act  =  act' 

map(U)  =  map'(U)  for  all  U  €  act  -  {T} 
mapff)  =  s 


Now  we  prove  that  this  implementation  is  a  correct  resilient  object 

l/cmma  41:  Let  a  be  a  well-formed  schedule  of  R(X)  which  can  leave  R(X)  in  state  (actmap). 
Then  act  coincides  with  the  set  of  transactions  which  arc  active  after  a. 

Proof:  The  proof  is  by  induction  on  the  length  of  a.  The  basis  is  trivial.  Let  a  =  a  w,  where  w 
is  a  single  operation.  'Ihcrc  arc  four  eases,  depending  on  the  type  of  operation  w.  Kach  is 
immediate  from  the  definition  of  active  and  the  implementation  of  R(X).  I 
tamma  42:  Let  a  be  a  well-formed  schedule  of  R(X)  which  can  leave  R(X)  in  state  (acimap). 
'lhcn  the  following  conditions  hold. 

•  undo(a)  is  a  schedule  of  basic  object  X  which  can  leave  X  in  state  map(lcast(acl».  and 

•  if  T*  is  any  transaction  other  than  T0,  and  oINFORM-  ABOR  T- ATfXjOFfO)  is  well- 
formed.  then  undo(alNFORM  -  AMOR  I'- A'l  (X)OFfr))  is  a  schedule  of  basic  object  X 
which  can  leave  X  in  state  mapfU).  where  U  is  the  least  element  of  act  which  is  not  a 
descendant  of  T. 

Proof:  First,  observe  that  if  T  is  not  an  ancestor  of  leas  t(  act),  and 
aINFORM-  ABORT- AT(XK>F(T)  is  well-formed,  then  Lemmas  41  and  39  imply  that 
undo(alNFORM-AllORT-AT(X)OF(T))  =  undo(o).  so  the  second  condition  follows  from 
the  first. 


Ihc  proof  is  by  induction  on  the  length  of «.  In  each  ease,  we  prove  the  first  condition,  then  the 
second  condition  assuming  that  T  is  an  ancestor  of  least(act).  Uy  the  observation  above,  this  is 
sufficient. 

Ihc  basis  is  trivial.  Let  a  =  a’*,  where  ir  is  a  single  operation.  Let  (acf.map')  be  a  state  of 
R(X)  after  a\  such  that  ((act'.indp').w,(act,map))  is  a  transition  for  R(X).  There  arc  four  eases. 


1) w  =  CRKATF/T) 

Ihen  undo! nr)  =  undo(a')w.  Uy  the  inductive  assumption,  undo(a')  is  a  schedule  of  X  which  can 
leave  X  in  stale  map'(lcasi(act')).  Hy  the  implementation  of  R(X).  (map'{lcast(acf  )),*.map(T))  is  a 
transition  of  X.  and  I  =  least!  act).  Thus  the  first  condition  of  the  lemma  is  satisfied. 

To  see  that  the  second  condition  holds,  note  that  all  active  transactions  after  a  arc  ancestors  of  T. 
and  by  well-formedness,  arc  exactly  the  transactions  active  after  a\  together  with  T.  I<ct  ip  be 
INFORM-  ABORT— AT(X)OF(r).  where  T  is  an  ancestor  off  other  than  Tfl.  and  a<p  is  well- 
formed.  Iff  is  a  proper  descendant  of  IcasUacf).  by  I  .emma  39,  undofn?)  =  undo!  a'),  which  is 
a  schedule  of  basic  object  X  which  can  leave  X  in  state  map(lcasi(acf ))),  by  the  inductive 
hypothesis.  If  T  is  an  ancestor  of  Icastfacf).  undofaq?)  =  undo(a'<p),  the  least  element  of  act 
which  is  not  a  descendant  off  is  also  the  least  element  of  act'  which  is  not  a  descendant  of  T,  and 
the  result  follows  by  the  inductive  hypothesis. 

2) »  =  RHQUKSI  -COMMl'KT.v) 

Then  undo(a)  =  undofa’)w.  Uy  the  inductive  assumption.  undo(a’>  is  a  schedule  of  X  which  can 
leave  X  in  state  map’(lcast(acf )).  Uy  the  implementation  of  R(X),  (map'(icasi(acf  )).w,map(T))  is  a 
transition  of  X.  and  T  =  least!  act).  Ihus  the  first  condition  of  the  lemma  is  satisfied. 

To  see  that  the  second  condition  holds,  note  that  the  active  transactions  after  a  arc  all  ancestors 
of  T.  and  by  well-formedness,  arc  exactly  the  transactions  active  after  a',  lxt  <p  be 
INFORM  -  AUORT-  AT(X)OF(T).  where  T  is  an  ancestor  of  T  other  than  T0.  and  aq>  is  well- 
formed.  Then  undofa^p)  =  undofa'qp).  which  is  a  schedule  of  basic  object  X  which  can  leave  X  in 
state  mapflcastfacf ))),  by  the  inductive  hypothesis.  Furthermore,  the  least  element  of  act  which  is 
not  a  descendant  of  T  is  also  the  least  element  of  act’  which  is  not  a  descendant  of  T.  and  the 
result  follows  by  the  inductive  hypothesis. 

3) ir  =  INFORM -COMMIT- AT(X)OK(T) 

'Ihen  undo( a)  =  undo(a‘).  Also,  map(lcast(act))  =  map(least(acf)),  by  definition  of  R(X).  The 
first  condition  follows. 


Uy  the  definition  of  R(X),  lcast(act)  is  an  ancestor  of  least! act’).  I-ct  9  be 

INFORM  —  AUORT—  AT(X)OF(T),  where  T  is  an  ancestor  of  least! act)  other  than  Tfl.  and  aq>  is 
well-formed.  'Ihen  0*9  is  well-formed,  and  undo{a?>)  =  undofa'qp).  Also,  since  aq>  is  well- 
formed,  T  *  T.  Let  U  and  U’  be  the  least  elements  of  act  and  act’,  respectively,  which  arc  not 
descendants  of  T. 


If  T  C  act’,  or  if  U  *  parcnt(T),  then  U  =  U’  and  map(U)  =  map’(U’).  and  the  second 
condition  follows  from  the  inductive  hypothesis.  So  assume  that  T  €  act’  and  U  =  parcnt(T). 
Then  since  T  *  T,  it  follows  that  U'  =  T.  Ihen  map’(U’)  =  map(U),  and  the  second  condition 
again  follows  from  the  inductive  hypothesis. 
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4)tr  =  INFORM  — ABORT— AT(X)OF(T) 

in-  is  not  an  ancestor  oflcastfiict').  then  undo(a)  =  undo(a’),  by  l.cmma  39.  Furthermore,  the 
state  ol"  K(X)  is  not  changed.  aINFORM- ABORT- AT(X)-OF(T)  is  well-formed  only  if 
aTNFORM- ABORT- AT(X)-OF(T)  is.  and  the  active  transactions  after  a  arc  exactly  those 
active  after  a'.  The  result  follows. 

Suppose  that  T  is  an  ancestor  of  lcast(act').  'Ihc  first  condition  is  immediate  from  the  inductive 
hypothesis.  Let  9  be  INFORM- ABORT- AT(X)OF(T).  where  T  ;s  an  ancestor  of  lcast(act) 
other  than  Tn,  and  a<p  is  well-formed.  Since  act  =  act'  -  dcsccndanls(  l ).  Icast(acl).  and  hence  T, 
is  an  ancestor  of  T.  undo(a9)  =  undo(a'«9)  =  undo(a  <p).  and  the  second  condition  follows  as 
well.  I 

Theorem  43:  R(X)  is  a  resilient  object. 

Proof:  We  must  show  that  R(X)  preserves  well-formedness  and  satisfies  the  resiliency  condition. 
'ITiai  R(X)  satisfies  the  resiliency  condition  follows  immediately  from  l.cmma  42. 

Assume  that  a  is  a  well-formed  schedule  of  R(X)  and  ir  is  an  output  operation  of  R(X)  enabled 
after  an  execution  with  schedule  o.  We  must  show  that  an  is  a  well-formed  sequence  of  R(Xp 
operations. 

Since  w  is  an  output,  it  has  the  form  R  KQU  FIST- COM  MITfl.v)  for  some  access  I  and  value  v. 
l  et  (act,map)  be  a  state  of  R(X)  after  o.  such  that  ir  is  enabled  in  (act. map).  Clearly,  n  is  an 
output  of  basic  object  X  enabled  from  state  map(lcast(act)).  By  Lemma  42,  undo(a)  is  a  schedule 
of  basic  object  X  which  can  leave  X  in  state  map(lcast(act))>.  so  undo(a)v  =  undo(aw)  is  a 
schedule  of  basic  object  X. 

Since  X  preserves  well-formedness  for  basic  objects,  and  by  Lemma  40  undo(a)  is  a  well-formed 
sequence  of  X-operations.  undo(a)  ends  with  the  operation  9  =  CRFATK(T)  and  contains  no 
other  operations  with  transaction  T.  Let  be  the  prefix  of  a  ending  in  9.  Suppose  first  that  a 
RKQUFST-COMMIT  for  T  occurs  in  o.  Since  a  is  well-formed,  9  is  the  only  CRKATHfO 
operation  in  a.  and  by  Lemma  34,  the  second  RKQUHST-CRKATH  for  T  follows  9.  and  by  the 
definition  of  undo,  is  in  undo(a)  if  9  is,  a  contradiction. 

It  remains  to  show  that  T  is  active  after  a.  By  Lemma  34,  T  is  active  after  ft 9.  No 
INFORM -COMMIT  for  T  can  occur  after  9  in  a.  since  by  well-formedness,  there  is  no 
RKQUKST-COMMIT  for  T  in  a.  Also,  since  9  is  in  undo(a).  no  INFORM- ABORT  for  an 
ancestor  of  T  can  occur  after  9  in  a.  'fhus  T  is  still  active  after  a.  I 


5.  Concurrent  Systems 

As  with  serial  schedules  in  classical  settings,  our  serial  schedules  contain  no  concurrency  or  resiliency  and 
thus  arc  too  inefficient  to  use  in  practice,  'rheir  importance  is  solely  for  defining  correctness  for  transaction 
systems.  In  this  section,  we  define  a  new  kind  of  system  called  a  concurrent  system.  'ITic  new  system  consists 
of  the  same  transactions  as  in  a  serial  system,  a  resilient  object  R(X)  for  every  basic  object  X  of  the  serial 
system,  and  a  concurrent  scheduler. 

Concurrent  systems  describe  computations  in  which  transactions  run  concurrently  and  can  be  aborted  after 


they  have  performed  some  work,  Hie  concurrcni  scheduler  has  the  joint  responsibility  of  controlling 
concurrency  and  of  seeing  that  the  effects  of  aborted  transactions  (and  their  descendants)  become  undone. 
Concurrent  systems  make  use  of  the  roll-hack  capabilities  of  resilient  objects  to  make  sure  that  ABORT 
operations  in  concurrent  systems  have  the  same  semantics  (so  far  as  the  transactions  can  tell)  as  they  do  in 
serial  systems. 

Concurrent  systems  are  defined  in  this  section.  In  the  next  section,  the  more  permissive  "weak  concurrent 
systems”  arc  defined.  In  Section  7,  we  prove  that  the  schedules  of  concurrent  systems  arc  serially  correct,  as  a 
corollary  of  a  weaker  correctness  property  for  the  weak  concurrent  system. 


5.1.  Ix>ck  Managers 

The  scheduler  we  define  is  called  the  concurrent  scheduler.  It  is  composed  of  several  automata:  a  lock 
manager  for  every  object  X.  and  a  single  concurrent  controller.  The  job  of  the  lock  managers  is  to  insure  that 
the  associated  object  receives  no  CRKATKS  until  the  lock  manager  has  received  abort  or  commit  information 
for  all  necessary  preceding  transactions.  This  lock  manager  models  an  exclusive  locking  protocol  derived 
from  Moss'  algorithm  [Mo],  Ilie  lock  manager  has  the  following  operations. 

Input  Operations: 

INTKRNAI.-CRKATFXT),  where  T  is  an  access  U>  X 
INFORM  -COMMIT-  AT(X)OK(T).  for  T any  transaction 
INFORM  -  ABORT- AT(X)OF(T),  for  T  any  transaction 

Output  Operations: 

CRHATHf T).  where  T  is  an  access  to  X 


Ilie  input  operations  INTKRNAI.— CRKATF,  INFORM-COMMIT  and  INFORM -ABORT  will 
compose  with  corresponding  output  operations  of  the  concurrent  scheduler  which  we  will  construct  in  this 
subsection.  The  output  CRKA  TF  operation  composes  with  the  CRKATF  input  operation  of  the  resilient 
object  R(X).  The  lock  manager  receives  and  manages  requests  to  access  object  X,  using  a  hierarchical  locking 
scheme.  It  uses  information  about  the  commit  and  abort  of  transactions  to  decide  when  to  release  locks. 

Kach  state  s  of  the  lock  manager  consists  of  the  following  three  sets  of  transactions:  lock-holders(s), 
create  -  rcqucstcd(s),  and  crcatcd(s).  Initially,  lock -holders  =  {TQ},  and  the  other  sets  arc  empty.  Ilie 
operations  work  as  follows. 

•  INTKRNAI.— CREATE(T) 

Postcondition: 

create -rcqucstcd(s)  =  create  -  rcqucstcd(s’)  U  {T} 

•  INFORM -COMMIT- AT(X)OF(T) 
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Postcondition: 

ifT€  lock  -  holders')  then  lock  -  holders)  =  (lock-holdcrs(s')-  {Tj)U  {parcntfl')} 

•  INFORM -AllORT-AT(X)OF<T) 

Postcondition: 

lock  -  holders)  =  lock  -  holders’)  -  dcsccndants(T) 

•  crkathto 

Precondition: 

T  €  create  -  rcqucstcd( s')  -  crcatcd(s’) 
lock  -  holders(s’)  C  anccstors(T) 

Postcondition: 

lock-holdcrs(s)  =  lock  -  holders')  U  {T} 
crcatcd(s)  =  crcatcd(s’)  U  {T} 


Note  that  resilient  object  R(X)  and  the  lock  manager  for  X  share  the  INFORM -ABORT  and 
INFORM-COMMIT  input  operations.  111080  compose  with  the  output  from  the  concurrent  controller 
defined  below. 

Thus,  the  lock  manager  only  sends  a  CRKATFXT)  operation  on  to  the  object  in  ease  all  the  current 
lock -holders  arc  ancestors  of  T.  When  the  lock  manager  learns  about  the  commit  of  a  transaction  T  for 
which  it  holds  a  lock,  it  releases  the  lock  to  Ts  parent  When  the  lock  manager  teams  about  the  abort  of  a 
transaction  T  for  which  it  holds  a  lock,  it  simply  releases  all  locks  held  by  that  transaction  and  its  descendants. 
Our  model  provides  an  exceptionally  simple  and  clear  way  of  describing  this  important  algorithm. 


A  key  property  of  lock  managers  is  described  by  the  following  lemma. 

l/cmma  44:  I xt  X  be  an  object  and  let  T  and  T  be  accesses  to  X.  Let  U  be  an  ancestor  of  T 
which  is  not  an  ancestor  of  T.  Let  a  be  a  schedule  of  the  lock  manager  for  X.  If  CRKATFXT) 
precedes  CRKATFXT)  in  a,  then  between  the  two  CRKATK  operations,  there  is  either  an 
INFORM— COMMIT— AT(X)OF(U)  operation,  or  else  an  INFORM- ABORT- AT(X)  for 
some  ancestor  of  T. 

Proof:  At  the  time  the  CRKATFXT)  occurs,  the  lock  manager  puts  T  into  the  set  of 
lock  -  holders.  Before  the  lock  manager  can  send  in  CRKATFXT),  it  must  be  that  all  the 
transactions  in  lock- holders  arc  ancestors  of  T.  There  arc  only  two  ways  in  which  this  can 
happen.  One  possibility  is  that  the  lock  manager  first  receives  INFORM -COMMITS  for  all 
ancestors  of  T  up  to  lca(T,T),  including  INFORM— COMMIT— AT(X)OF(U).  The  other 
possibility  is  that  the  lock  manager  first  receives  an  INFORM  -  ABORT  for  an  ancestor  of  T.  I 

5.2.  The  Concurrent  Controller 

The  concurrent  controller  is  similar  to  the  serial  scheduler,  but  it  allows  siblings  to  proceed  concurrently.  In 
order  to  manage  this  properly,  it  interacts  with  "concurrent  objects"  (lock  managers  and  resilient  objects) 
instead  of  just  basic  objects.  The  operations  arc  as  follows. 
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Input  Operations: 

rhquist-crkathxt) 

RHQUKST-COMMIT(T,v) 

Output  Operations: 

CRKATHf T).  T  a  non-access  transaction 
INTERNAL— CR HA  TI'X'I  ).  T  an  access  transaction 
COMMII(T.v) 

AHORI(T) 

INFORM  -COMMIT- AT(X)OK(T) 

INFORM  — ABORT— AT(X)OF(T) 

Kach  state  s  of  the  concurrent  controller  consists  of  five  sets:  create- rcqucstcd(s),  crcatcd(s). 
commit- rcqucstcd(s),  committcd(s).  and  abortcd(s).  1110  set  commit- requcstcd(s)  is  a  set  of 
(transaction, value)  pairs,  and  the  others  arc  sets  of  transactions.  (As  before,  we  will  occasionally  write  T  € 
commit— rcqucstcd(s)  for  (T.v)  €  commit— rcqucstcd(s)  for  some  v.)  All  sets  arc  initially  empty  except  for 
create- requested,  which  is  {Tfl}.  Define  rctumcd(s)  =  committcd(s)  U  abortcd(s).  Ihc  operations  arc  as 
follows. 

•  RHQUHST-CRHA I  HfO 

Postcondition: 

create- rcqucstcd(s)  =  create -rcqucstcd(s')U  {T} 

•  RHQU  HST— COM  M  IT(T»v) 

Postcondition: 

commit- rcqucstcd(s)  =  commit-  rcqucsted(s’)  U  {(T.v)} 

•  CRKATFXT).  T  a  non-access  transaction 
Precondition: 

T  €  create  -  requcstcd(s')  *  creatcd(s') 

Postcondition: 

creatcd(s)  =  crcatcd(s')  U  {T} 

•  INTHRNAL-CREATK(T),Tan  access  transaction 
Precondition: 

T  €  create  -  rcqucstcd(s')  -  created^') 

Postcondition: 

creatcd(s)  =  crcated(s')  U  {T} 

•  COMMIT(T,v) 

Precondition: 

(T.v)  €  commit  -  requested^’) 

T  t  rctumcd(s’) 

childrcn(T)  0  create  -  rcqucstcd(s’)  C  rctumcd(s’) 

Postcondition: 

committcd(s)  =  committed^’)  U  {T} 


•  ABORTfl) 

Precondition: 

T  €  (crcatc-rcqucstcd(s’)  -  crcatcd(s’))  U  (commit-  rcqucstcd(s’)  -  rcturncd(s')) 
childrcn(T)  fl  create— rcqucstcd(  s’)  C  rcturned(s’) 

Postcondition: 

crcatcd(s)  =  crcatcd(s’)  U  {'I'} 
ahortcd(s)  =  abortcd(s')  U  {‘1’} 

•  INFORM— COMMIT— AT(X)OF(T): 

Precondition: 

T  €  committcd(s’) 

•  INFORM  -  A BORT— AT(X)OF(T): 

Precondition: 

T  €  abortcd(s’) 

ITic  concurrent  controller  is  closely  related  to  the  serial  scheduler.  In  place  of  the  serial  scheduler's 
CRKATF.  operations,  the  concurrent  controller  has  two  kinds  of  operations,  CRKATK  operations  and 
INTKRNAI.-CRHATH  operations.  Hie  former  is  used  for  interaction  with  non-access  transactions,  while 
the  latter  is  used  for  interaction  with  access  transactions.  From  the  concurrent  controller’s  viewpoint,  the  two 
operations  arc  the  same:  however,  our  naming  convention  for  operations  requires  us  to  assign  them  different 
names,  since  the  INTKRNAI. -CRKATK  operations  arc  intended  to  be  identified  with 
INTKRNAI.— CRKATK  operations  of  the  lock  managers  (which  also  have  CRKATK  operations,  for 
interaction  with  the  resilient  objects).  'Ihc  precondition  on  the  serial  scheduler’s  CRKATK  operation  which 
insures  serial  processing  of  sibling  transactions,  docs  not  appear  in  the  concurrent  controller.  Thus,  the 
concurrent  controller  may  run  any  number  of  sibling  transactions  concurrently,  provided  their  parent  has 
requested  their  creation. 

'Hie  concurrent  controller’s  COMMIT  operation  is  the  same  as  the  serial  scheduler’s  COMMIT  operation 
(except  for  a  minor  difference  in  b<x)k keeping).  The  concurrent  controller’s  ABORT  operation  is  different, 
however:  in  addition  to  aborting  a  transaction  in  the  way  that  the  serial  scheduler  docs,  the  concurrent 
controller  has  the  additional  capability  to  abort  a  transaction  that  has  actually  been  created  and  has  carried  out 
some  steps.  In  this  particular  formulation,  aborts  occur  if  the  transaction  was  not  created  (as  with  the  serial 
scheduler),  or  if  the  transaction  has  previously  requested  to  commit,  and  its  children  have  returned.  egether 
with  the  requirements  on  the  COMMIT  operation,  this  condition  insures  that  all  transaction  completion 
occurs  bottom-up.  In  the  weak  concurrent  system  to  be  considered  in  Section  6,  a  different,  "weak”, 
concurrent  controller  will  be  used:  it  differs  from  the  concurrent  controller  of  this  section  precisely  in  not 
requiring  ABORT  operations  to  wait  for  their  transactions  (and  subtransactions)  to  complete. 

T"hc  concurrent  controller  also  has  two  additional  operations  not  present  in  the  serial  scheduler,  These 
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operations  allow  the  concurrent  controller  to  forward  necessary  abort  and  commit  information  to  the  lock 
managers  and  resilient  objects. 

I  emma  45:  I  .ct  a  be  a  schedule  of  the  concurrent  scheduler,  and  let  s  be  a  state  which  can  result 
from  applying  a  to  the  initial  suite.  Then  die  following  conditions  arc  true. 

1.  T  is  in  create- rcqucsted(s)  exactly  if  T  =  l'0  or  a  contains  a  IUiQUKST-CRKATK(T) 
operation. 

2.  If  T  is  a  non-access  transaction,  then  T  is  in  crcalcd(s)  exactly  if  a  contains  either  a 
CRKATKO)  »>r  AHORT(T)  operation. 

3.  If  T  is  an  access  transaction,  then  T  is  in  crcatcd(s)  exactly  if  a  contains  either  an 
INTKRNAI.-CRKA  I  TXT)  or  AHORT(T)  operation. 

4.  (T.v)  is  in  commit- rcqucstcd(s)  exactly  if  a  contains  a  COMMIT- RRQUKST(T,v) 
operation. 

5.  (T.v)  is  in  committcd(s)  exaedy  if  a  contains  a  COMMIT(T.v)  operation. 

6.  T  is  in  aborted(s)  exactly  if  a  contains  an  AHORT(T)  operation. 

5J.  Concurrent  Systems 

Ihc  composition  of  transactions,  resilient  objects  and  the  concurrent  scheduler  (lock  managers  and 
concurrent  controller)  is  the  concurrent  system.  A  schedule  of  the  concurrent  system  is  a  concurrent  schedule . 
and  the  operations  of  a  concurrent  system  arc  concurrent  operations. 

A  sequence  a  of  concurrent  operations  is  well-formed  if  for  every  primitive  P,  a|P  is  well-formed  (using  the 
appropriate  definition  of  well-formedness). 

Ihc  main  result  of  this  paper  is  that  every  concurrent  schedule  is  serially  correct.  Ihis  will  be  proved  as  a 
corollary  of  a  stronger  result,  in  Section  7. 

5.4.  Properties  of  Concurrent  Systems 

As  we  did  for  serial  schedules,  we  now  prove  some  useful  basic  properties  for  concurrent  schedules.  Ihcsc 
lemmas  describe  the  possible  kinds  and  orders  of  operations  that  can  occur  in  well-formed  concurrent 
schedules.  I^tcr,  we  will  see  that  all  concurrent  schedules  arc  well-formed,  so  these  properties  actually  follow 
just  from  the  fact  that  these  schedules  arc  concurrent  All  results  and  proofs  in  this  subsection  arc 
straightforward. 

tamma  46:  l.ct  a  be  a  well-formed  concurrent  schedule,  and  let  T  *  Tfl  be  a  transaction. 

1.  If  a  contains  any  operation  with  transaction  T.  then  a  contains  a  CREATFXT)  and  a 
RhX)U  HST-  CRKATHf  0. 
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2.  If  a  contains  a  COMMIT  for  T,  then  a  contains  a  RKQUKST-COMMIT  for  T,  a 
CRKATIXT)  and  a  RKQUKST-CRKATIXT). 


3.  If  a  contains  an  AHORT(T).  then  a  contains  a  RKQUKST- CRKATKXT). 

lamina  47: 1  ct  a  be  a  well-formed  concurrent  schedule,  and  T  a  transaction.  Assume  that  some 
descendant  of  T  is  in  transiiclion(a).  Then  the  following  hold. 

1.  CRKATKXT)  occurs  in  a. 

2.  If  T  *■  T0,  then  RKQUKST- CRHA'ITX'I  )  occurs  in  a. 

lemma  48: 1  xt  a  be  a  well-formed  concurrent  schedule,  and  let  T  *  T0  be  a  transaction. 

1.  If  a  contains  a  RKQUKST-CRKATIXT).  but  docs  not  contain  a  return  operation  for  T. 
then  parcnU'l')  is  live  in  a. 

2.  If  T  is  live  in  a,  then  purenUT)  is  live  in  a. 

3.  If  a  contains  a  RKQUKST— CRKATKXT)  but  docs  not  contain  a  CRKAITXT)  or 
AIJORT(T).  then  parcnt('r)  is  live  in  a. 

Proof:  1.  Well-formedness  implies  that  the  RKQUKST -CRKATKXT)  is  preceded  by  a 
CRKATKXparcnUT)).  Suppose  that  parcnUl)  is  not  live  in  a.  Then  a  return  operation  for 
parcnt(T)  occurs  in  a.  In  ease  the  return  operation  for  parcnU'l  )  is  an  AUORT(parcnt(T)), 
scheduler  preconditions  imply  that  the  CRKATKXparcnUT))  must  precede  the 
AROR  T(parcnt(T)).  Then  the  scheduler  preconditions  for  the  return  operation  imply  that  the 
return  for  parcnU'l  )  must  be  preceded  by  a  RKQUKST-COMMIT  for  parcnt(T).  I)y  well- 
formedness.  the  RKQUKST-COMMIT  for  parcnU'l  )  must  follow  die  RKQUKST- CRKATKXT). 
so  that  the  return  for  parcnU'l  )  must  follow  the  RKQUKST-CRKATK(T)  'Ihcn  the  scheduler 
preconditions  for  the  return  operation  imply  that  there  must  be  a  return  operation  for  T  in  a,  a 
contradiction. 

2.  and  3.  arc  as  in  lemma  17.  I 

lyvmma  49: 1  .ct  a  be  a  well-formed  concurrent  schedule,  and  let  T  be  a  transaction. 

1.  If  a  contains  a  RKQUKST— CRKATK(T),  but  docs  not  contain  a  return  operation  forT. 
then  all  proper  ancestors  of  T  arc  live  in  a. 

2.  IfT  is  live  in  a,  then  any  ancestor  ofT  is  live  in  a. 

3.  If  a  contains  a  RKQUKST— CRKATKfO  but  docs  not  contain  a  CRKATEfO  or 
AUORT(T).  then  all  proper  ancestors  of  T  arc  live  in  a. 

Lemma  50: 1  xt  a  be  a  well-formed  concurrent  schedule,  and  let  T  and  T  be  transactions  with  T 
a  descendant  of  T.  Assume  that  there  is  a  return  operation  for  T  in  a. 

1.  If  there  is  a  RKQUKST- CRKA  l’K(T)  in  a,  then  there  is  a  return  operation  forT  in  a. 

2.  IfT*  is  in  transaction(a).  then  there  is  a  return  operation  forT  in  a. 

Proof: 


1.  By  I  cmma  49. 


2.  By  I  .cmma  46  and  part  1. 

I 

U-mma  51:  Let  a  be  a  well-formed  concurrent  schedule.  Ifa  return  operation  for  T  is  in  a .  then 
it  follows  all  operations  in  a  whose  transaction  is  T. 

Proof:  First  consider  the  ease  where  T  is  not  an  access.  If  no  CRKATKfT)  occurs  in  a.  the  result 
is  immediate,  so  assume  that  CRKATKfT)  occurs  in  a.  In  ease  an  ABOR  1(1)  occurs  in  o, 
scheduler  preconditions  imply  that  the  CRKATKXT)  must  precede  llic  ABOR  1(1).  'ITicn  the 
return  operation  for  T  must  be  preceded  by  a  RKQUKST- COMM  IT  for  T.  by  scheduler 
preconditions.  Well-formedness  implies  that  the  RKQUKST— COMMIT  is  preceded  by 
CRKATKfT).  and  is  not  followed  by  any  output  operations  of  T.  'ITtus.  the  only  serial  operations 
of  f  that  could  follow  the  RKQUKST -COM  MIT  arc  return  operations  of  children  ofT. 

I  ct  T  be  a  child  of  T  for  which  a  return  operation  occurs  in  a.  By  scheduler  preconditions, 
there  is  only  one  return  operation  for  T  in  a.  By  Lemma  46.  a  also  contains 
RKQUKST— CRKATKfT).  Since  this  is  an  output  operation  of  T,  it  precedes  the 
RKQUKST— COMMIT  for  T,  and  hence  precedes  the  return  operation  forT.  ITicn  the  scheduler 
preconditions  imply  that  the  return  operation  forT  precedes  the  return  forT. 

Next,  consider  the  ease  where  T  is  an  access.  If  no  INTKRNAL— CRKATKf  0  occurs  in  a,  the 
result  is  immediate,  so  assume  that  INTKRNAL— CRKATKXT)  occurs  in  a.  In  case  an 
ABORTfT)  occurs  in  «,  scheduler  preconditions  imply  that  the  INTKRNAL— CRKATKXT)  must 
precede  the  ABORT(T).  'Then  the  return  operation  for  T  must  be  preceded  by  a 
RKQUKST— COMMIT  for  T.  and  well-formedness  implies  that  this  is  in  turn  preceded  by 
CRKATKfT).  'Thus,  no  serial  operations  off  can  follow  the  return  operation  for  T.  I 

I  .cmma  52:  Let  a  be  a  well-formed  concurrent  schedule.  If  a  return  operation  forT  is  in  a,  then 
it  follows  all  operations  in  a  whose  transactions  arc  descendants  of  T. 

Proof:  Since  a  return  operation  for  T  occurs  in  a,  we  have  T  *  TQ.  I.ct  T  be  a  descendant  of  T, 
and  assume  for  the  sake  of  obtaining  a  contradiction  that  a  serial  operation  w  with  transaction^) 

=  T  occurs  after  the  return  for  T  in  a.  Let  a  be  the  prefix  of  a  preceding  w. 

By  Lemma  46,  a'  contains  a  RKQUKST— CRKATKfT).  Then  Ixmma  50  implies  that  o'  must 
contain  a  return  operation  for  T.  But  then  the  well-formed  schedule  aw  contains  a  return 
operation  forT  followed  by  an  operation  ofT,  which  contradicts  Lemma  51.  I 

Weak  concurrent  systems  arc  defined  in  the  following  section,  and  many  of  their  properties  arc  stated  and 
proved.  Weak  concurrent  systems  arc  obtained  by  replacing  the  concurrent  scheduler  with  a  more  permissive 
scheduler,  the  weak  concurrent  scheduler.  Results  in  Section  7  prove  that  every  execution  of  the  concurrent 
system  is  also  an  execution  of  the  weak  concurrent  system.  Thus,  additional  interesting  properties  of 
concurrent  system  behavior  follow  immediately  from  the  corresponding  properties  of  weak  concurrent  system 
behavior,  proven  in  that  section. 


40 

6.  Weak  Concurrent  Systems 

In  this  section,  we  define  "weak  concurrent  systems",  which  arc  exactly  the  same  as  concurrent  systems, 
except  that  they  have  a  more  permissive  controller,  the  "weak  concurrent  controller”.  The  weak  concurrent 
controller  reports  aborts  to  a  transaction's  parent  while  there  is  still  activity  going  on  in  the  aborted 
transaction’s  subtree.  In  this  paper,  weak  concurrent  systems  arc  used  primarily  to  provide  an  intermediate 
step  in  proving  the  correctness  of  concurrent  systems:  proving  a  weaker  condition  for  weak  concurrent 
systems  allows  us  to  infer  the  stronger  correctness  condition  for  concurrent  systems.  However,  weak 
concurrent  systems  arc  also  of  interest  in  themselves.  In  a  distributed  implementation  of  a  nested  transaction 
system,  performance  considerations  may  make  it  important  for  the  system  to  allow  a  transaction  to  abort 
without  waiting  for  activity  in  the  transaction's  subtree  to  subside.  In  this  ease,  a  weak  concurrent  system 
might  be  an  appropriate  choice,  even  though  the  correctness  conditions  which  they  satisfy  arc  weaker.  Weak 
concurrent  systems  also  appears  to  have  further  technical  use.  for  example  in  providing  simple  explanations  of 
the  ideas  used  in  "orphan  detection"  algorithms  [HI. MW]. 

6.1.  The  Weak  Concurrent  Controller 

In  this  subsection,  we  define  the  weak  concurrent  controller.  As  we  have  already  said,  it  is  identical  to  the 
concurrent  controller  except  that  it  has  a  more  permissive  ABORT  operation.  For  convenience,  we  describe 
the  controller  here  in  its  entirety.  It  has  the  same  operations  as  the  concurrent  controller: 

Input  Operations: 

R  KQU  KST- CRKATKf  0 
RHQU  KST  -  COM  M  Iff  l’,v) 


Output  Operations: 

CRFATHO  ).  T  a  non-access  transaction 
I NTKRNAI.- CRKATKf T),  T  an  access  transaction 
COMMITfO) 

ARORTfO 

INFORM -COMMIT- AI(X)OFCI’) 

INFORM  -  ABORT-  A  I  (X)OFCr) 

Each  state  s  of  the  concurrent  controller  consists  of  five  sets:  create -rcqucstcd(s),  crcatcd(s), 
commit— rcqucstcd(s),  committcd(s),  and  abortcd(s).  The  set  commit—  rcqucstcd(s)  is  a  set  of 
(transaction, value)  pairs,  and  the  others  arc  sets  of  transactions.  (As  before,  we  will  occasionally  write  T  € 
commit— rcqucstcd(s)  for  (T,v)  €  commit— rcqucstcd(s)  for  some  v.)  All  arc  empty  initially  except  for 
create -requested,  which  is  {Tfl}.  Define  rctumcd(s)  =  committcd(s)  U  abortcd(s).  'Die  operations  arc  as 
follows. 

•  R  KQU  KST- CRKATKf  D 
Postcondition: 


create -rcqucsted(s)  =  create- requested!*')  U  {T} 


•  RHQUIST-COMMITO'.v) 

Postcondition: 

commit- rcqucstcd(s)  =  commit  -  rcqucstcd(s')  U  {(T.v)} 

•  CRFATITI).  T  a  non-access  transaction 
Precondition: 

I  €  create  -  rcqucstcd( s')  -  crcatcd(s’) 

Postcondition: 

crcatcd(s)  =  crcatcd(s')  U  {T} 

•  INTKRNAI.— CRKATK(T), T an  access  transaction 
Precondition: 

T  €  create-  rcqucstcd(s')  -  crcatcd(s') 

Postcondition: 

crcatcd(s)  =  crcatcd(s')  U  {T} 

•  COMMH(T.v) 

Precondition: 

(T.v)  €  commit-  rcqucstcd(s') 

T  €  rctumcd(s’) 

childrcn(T)  D  create -rcqucstcd(s’)  C  rctumcd(s’) 

Postcondition: 

committcd(s)  =  committcd(s’)  U  {T} 

•  ABORT(T) 

Precondition: 

T  €  crcatc-requcstcd(s')  -  returncd(s’) 

Postcondition: 

crcatcd(s)  =  created^")  U  {T} 
abortcd(s)  =  abortcd(s')  U  {T} 

•  INFORM -COMMIT-  AT(X)OF(T): 

Precondition: 

T  €  committccKs’) 

•  INFORM- ABORT- AT(X)OF(T): 

Precondition: 

T  €  abortetKs’) 

Thus,  the  weak  concurrent  controller  is  permitted  to  abort  any  transaction  that  has  had  its  creation 
requested,  and  which  has  not  yet  returned. 

l/cmma  53: 1  xt  a  be  a  schedule  of  the  concurrent  scheduler,  and  let  s  be  a  state  which  can  result 
from  applying  a  to  the  initial  state.  Then  the  following  conditions  are  true. 

l.T  is  in  create  -  rcqucstcd(s)  exactly  if  T  =  TQ  or  a  contains  a  RF.QUKST -  CREATEfT) 
operation. 
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2.  If  T  is  a  non-access  transition,  then  T  is  in  crcated(s)  exactly  if  a  contains  either  a 
CRKATFX’f)  or  AHORT(T)  operation. 

.1.  If  T  is  an  access  transaction,  then  T  is  in  crcatcd(s)  exactly  if  a  contains  either  an 
IN'TF.RNAL— CRHATH(T)  or  AllORT(T)  operation. 

4.  (T.v)  is  in  commit- rcqucstcd(s)  exactly  if  a  contains  a  COMMIT—  RFQUHST(T,v) 
operation. 

5.  (T.v)  is  in  committcd(s)  exactly  if  a  contains  a  COMMIT(T,v)  operation. 

6.  T  is  in  abortcd(s)  exactly  if  a  contains  an  ARORTfT)  operation. 

6.2.  Weak  Concurrent  Systems 

ITic  composition  of  transactions,  resilient  objects  and  the  weak  concurrent  scheduler  (lock  managers  and 
weak  concurrent  controller)  is  the  weak  concurrent  system.  A  schedule  of  the  weak  concurrent  system  is  a 
weak  concurrent  schedule. 

Weak  concurrent  systems  exhibit  nice  behavior  to  transactions  except  possibly  to  those  which  arc 
descendants  of  aborted  transactions.  TTius.  we  say  that  a  transaction  T  is  an  orphan  in  any  sequence  a  of 
operations  provided  that  an  ancestor  of  T  is  aborted  in  a.  In  many  of  the  properties  we  prove  for  weak 
concurrent  systems,  we  will  have  to  specify  that  the  transactions  involved  arc  not  orphans. 

6J.  Properties  of  Weak  Concurrent  Systems 

As  we  did  for  serial  and  concurrent  schedules,  we  here  prove  a  number  of  useful  basic  properties  for  weak 
concurrent  schedules.  As  before,  most  of  these  properties  arc  simple  to  state  and  prove. 

63.1.  Operations  in  Weak  Concurrent  Schedules 

As  before,  we  include  a  collection  of  lemmas  describing  the  possible  kinds  and  orders  of  operations  that  can 
occur  in  well-formed  weak  concurrent  schedules.  ITicsc  lemmas  arc  analogous  to  some  in  Section  S,  and  have 
similar  proofs;  the  main  difference  is  that  we  must  take  proper  care  with  orphans.  As  before,  we  go  on  to 
show  that  all  weak  concurrent  schedules  arc  well-formed,  so  these  properties  actually  follow  just  from  the  fact 
that  these  schedules  arc  weak  concurrent 

Ivcmma  54:  Let  a  be  a  well-formed  weak  concurrent  schedule,  and  let  T  *  T0  be  a  transaction. 

1.  If  a  contains  any  operation  with  transaction  T,  then  a  contains  a  CRKATK(T).  and  a 
RLQU  HST  -  CRHATKfO. 

2.  If  a  contains  a  COMMIT  for  T.  then  a  contains  a  RFXJUKST-COMMIT  for  T.  a 
CRHATHfO  and  a  RI-QUKS  T-CRFATHfT). 

3.  If  a  contains  an  AIJORT(T).  then  a  contains  a  RKQUKST-CRKATH(T). 


>  y->v>*vw*  •y-yv> 
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Imuiia  SS:  l  et  a  he  a  well-formed  weak  concurrent  schedule,  and  T  a  transaction.  Assume  that 
some  descendant  of  I'  is  in  transaction^ ).  Then  the  following  hold. 

1.  CRKATLXT)  occurs  in  a. 

2.  If  l  *  l0.  then  RKQUKST-CRKATIXT)  occurs  in  a. 

l/cnmta  56:  Let  a  be  a  well-formed  weak  concurrent  schedule,  and  let  I'  *  Tfl. 

1.  If  a  contains  a  RKQUKST-CRKATIXT).  hut  docs  not  contain  a  return  operation  for  T, 
then  parcni(T)  is  not  committed  in  a. 

2.  If  T  is  live  in  a.  then  parcnt(T)  is  not  committed  in  a. 

3.  If  a  contains  a  RKQUKST-CRKATKff)  but  docs  not  contain  a  CRKATKfO  or 
ABORTfT),  then  parent!  I  )  is  not  committed  in  a. 

Proof:  1.  Suppose  a  COMMIT  operation  for  parent!  T)  occurs  in  a.  Ihcn  the  weak  concurrent 
controller  preconditions  for  the  COMMIT  operation  imply  that  the  COM  MIT  for  parentfO  must 
be  preceded  by  a  RKQUKST-COMMIT  for  parentfT).  By  well-formedness,  the 
RKQUKST-COMMIT  for  parent!'!')  must  follow  the  RKQUKST-CRKATIXT).  so  that  the 
COMMI  T  for  parent!  I  )  must  follow  the  RKQUKST-CRKATIXT).  I'hcn  the  weak  concurrent 
controller  preconditions  for  the  COMMIT  operation  imply  that  there  must  be  a  COMMIT 
operation  for  T  in  a.  a  contradiction. 

2.  and  3.  arc  as  in  3.6.2.  I 

Lemma  57:  Let  a  be  a  well-formed  weak  concurrent  schedule,  and  let  T  be  a  transaction  which 
is  not  an  orphan  in  a. 

1.  If  a  contains  a  RKQUKST-CRKATKff).  but  docs  not  contain  a  COMMI  T  operation  for 
T,  then  all  proper  ancestors  of  T  arc  live  in  a. 

2.  If  T  is  live  in  a.  then  all  proper  ancestors  of  T  arc  live  in  a. 

3.  If  a  contains  a  RKQUKST-CRKATKfT)  but  docs  not  contain  a  CRKA  TKfO,  then  all 
proper  ancestors  of  T  arc  live  in  o. 

Proof:  By  repeated  use  of  the  previous  lemma,  well-formedness  and  the  weak  concurrent 
controller  preconditions.  I 

tamma  58:  Let  a  be  a  well-formed  weak  concurrent  schedule,  and  let  T  and  T  be  transactions 
with  T  a  descendant  of  1'.  Assume  that  T  is  not  an  orphan  in  a  and  that  there  is  a  COMMIT 
operation  for  T  in  a. 

1.  If  there  is  a  RKQUKST-CRKATEfO  in  a,  then  there  is  a  COMMIT  operation  for  T  in 

a. 


2.  If  T  is  in  transaction(a),  then  there  is  a  COMMIT  operation  for  T  in  a. 

Proof: 

l.  By  I  -cmma  57. 


63.2.  Objects  and  lacking 

In  this  paragraph,  we  give  two  simple  lemmas  about  the  behavior  of  the  locking  strategy. 

Ix'mnia  59:  Let  a  be  a  weak  concurrent  schedule.  Let  X  be  an  object,  and  let  T  and  T  be 
accesses  to  X.  Let  U  be  an  ancestor  of  I'  which  is  not  an  ancestor  of  T.  Assume  that  CRHATK(T) 
precedes  CRHA'IFfO  in  a. 

l.’ITicrc  is  either  an  INFORM  — COMMIT— AT(X)OF(U).  or  else  an 
INFORM  -  ABORT- AT(X)  for  some  ancestor  off,  occurring  between  CRHATFX'f)  and 
CRHATH('r)in  a. 


2.  Hither  CRHATHfT)  is  preceded  by  a  COMMIT  operation  for  U.  and  by  a 
RF.QUHST-COMMIT  operation  for  U.  or  else  CRHATFX V)  is  preceded  by  an  ABORT 
operation  for  some  ancestor  of  T. 

Proof: 

1.  By  Lemma  44. 

2.  By  part  1  and  the  preconditions  of  the  weak  concurrent  controller. 

I 

Ixmma  60:  Let  a  be  a  well-formed  weak  concurrent  schedule,  and  X  a  basic  objeeL  'ITicn  the 
set  of  active  transactions  after  a|R(X)  is  exactly  the  set  of  lockholdcrs  in  the  lock  manager  for  X 
after  a. 

Proof:  By  induction  on  the  length  of  a.  I 
633.  Well-Formedness 

Here,  we  show  that  every  weak  concurrent  schedule  is  well-formed.  It  follows  that  all  the  properties  proved 
earlier  in  this  section  arc  actually  true  for  all  weak  concurrent  schedules.  From  now  on.  we  will  use  these 
properties  without  explicitly  mentioning  well-formedness. 

l/cmma  61:  Let  a  be  a  weak  concurrent  schedule.  'Chen  a  is  well-formed. 

Proof:  By  induction  on  the  length  of  schedules.  The  base,  length  =  0.  is  trivial.  Suppose  that 
atr  is  a  weak  concurrent  schedule,  where  ir  is  a  single  operation,  and  assume  that  a  is  well- 
formed.  If  v  is  an  output  of  a  primitive  P,  then  the  result  is  immediate,  since  each  primitive 
preserves  well-formedness.  No  INTKRNAL-CRHATK  operation  can  cause  a  violation.  So 
assume  that  w  is  an  input  to  a  primitive  P.  It  suffices  to  show  that  a«jP  is  well-formed.  'Phcrc  arc 
six  eases. 

( 1 )  w  is  CRKATK(T)  and  T  is  a  non-access  transaction. 

I'hc  controller  preconditions  insure  that  CRHATKfO  docs  not  appear  in  a. 

(2)  w  is  CRHATHCO  and  T  is  an  access  to  resilient  object  R(X). 

By  the  lock  manager  preconditions,  no  CRHATH(T)  appears  in  a.  I'hc  lock  manager 
preconditions  and  Lemma  60  imply  that  all  the  transactions  which  arc  active  after  a  arc  ancestors 
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off. 

(3)  it  isCOMMITfl'.v). 

I  hen  w  is  an  input  to  transaction  parenUT).  Weak  concurrent  controller  preconditions  imply  that 
a  contains  RFQUFST— COMMITf T.v).  and  so  Lemma  54  implies  that  a  contains 
RFQUFST— CRKATlif T).  Also,  weak  concurrent  controller  preconditions  insure  that  a  docs  not 
contain  a  return  operation  forT. 

(4)  w  isAHOR  I(  l  ). 

Then  w  is  an  input  to  transaction  parcnt(T).  Weak  concurrent  controller  preconditions  imply  that 
a  contains  a  RFQUFST— CRFA TFf T).  Weak  concurrent  controller  preconditions  insure  that  a 
docs  not  contain  a  return  operation  for  '1'. 

(5)  w  is  INFORM -COMM IT-  AT(X)OF<T)  at  resilient  object  R(X). 

By  the  preconditions  of  the  weak  controller,  a  contains  a  COMMIT  for  T.  If 
INFORM  —  ABORT— AT(X)OF(T)  occurs  in  a.  then  a  also  contains  an  ABORT  for  T,  which 
contradicts  weak  concurrent  controller  preconditions.  Thus,  no 

INFORM- ABORT- AT(X)OF(T)  occurs  in  a.  Since  a  COMMIT  for  T  occurs  in  a,  weak 
concurrent  controller  preconditions  imply  that  a  R  KQU  FST—  COM  Mil  forT  also  occurs  in  a. 

(6)  w  is  INFORM  — ABORT- AT(X)OF(T)  at  resilient  object  R(X). 

By  the  preconditions  of  the  weak  concurrent  controller,  a  contains  ABORTCT).  If 
INFORM-COMMIT- AT(X)OF(T)  occurs  in  a.  then  a  contains  a  COMMIT  for  T.  which 
contradicts  weak  concurrent  controller  preconditions.  Ilius,  no 

INFORM— COMMIT- AT(X)OF(T) occurs  in  a.  I 

63.4.  Visibility  and  Weak  Concurrent  Schedules 

ITiis  paragraph  states  and  proves  important  properties  involving  visibility  in  weak  concurrent  schedules.  In 
particular,  the  most  important  result  of  this  paragraph  is  Lemma  66.  which  relates  the  portion  of  a  weak 
concurrent  schedule  which  is  visible  to  a  particular  transaction,  to  schedules  of  transactions  and  basic  objects. 
The  first  lemma  shows  how  visibility  propagates  among  the  transactions  during  a  weak  concurrent  execution, 
lemma  62:  Let  aw  be  a  weak  concurrent  schedule,  where  w  is  a  single  operation. 

1.  If  w  isCRKATKCT),  then  visiblc(aw,T)  =  visiblc(a.parcnt(T))w. 

2.  Ifw  is  COMM  TTfT.v),  then  visiblc(aw,parcnt(T))  =  visiblc(a,T)w. 

3.  If  w  is  ABORT(T),  then  visib1c(aw.parcnt(T))  =  visiblc(a,parcnt(T))w. 

4.  If  w  is  COMMITfT.v),  and  T  is  a  descendant  of  parcnt(T)  but  not  T,  then  visiblc(aw,T)  * 
visiblc(aw.parcnt(T))  =  visiblc(  a.T)  ■  visiblc(a,T)- 

Proof:  1.  By  Lemma  55,  w  is  the  first  serial  operation  in  aw  whose  transaction  is  a  descendant  of 
T.  and  T  is  not  visible  to  parcnt('T).  ’Ilnis  any  transaction  other  than  T  visible  to  T  in  aw  is  visible 
to  purcntCO  in  aw.  Then  parcnt('T)  is  visible  to  T  in  aw.  and  by  Lemma  8, 
visiblc(aw.parcnt(T))w  =  visiblc(aw,T). 
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By  Ihc  definition  of  visibility,  any  transaction  visible  to  parent!!)  in  aw  is  visible  to  parcnlfT)  in 
a.  and  visiblc(a.purcnl(T))  =  visiblc<aw.parcnt(T)).  Substituting  in  the  equality  above,  we  have 
the  result. 

2.  Hy  the  definition  of  visibility,  any  transaction  visible  to  parentfT)  in  aw  is  either  visible  to 
parent! T)  in  a,  or  is  visible  to  T  in  a.  Hill  any  transaction  visible  to  parcnl(T)  in  a  is  visible  to  T  in 
a.  so  we  have  that  any  transaction  visible  to  parent!  I  )  in  aw  is  visible  to  T  in  a.  and 
visible! aw. parent!  I))  is  a  subsequence  of  visible!  a, T)w.  It  follows  immediately  from  the 
definition  of  visibility  that  any  transaction  visible  to  T  in  a  is  visible  to  parent!  I  )  in  aw,  so  that 
visiblcfa.T)  is  a  subsequence  of  visiblc(aw.parcnt(T).  I  hc  result  is  immediate. 


3.  Immediate  from  the  definition  of  visibility. 

4.  Clearly,  visiblcfa.T)  is  a  subsequence  of  visiblcfaw.T).  Any  operation  in  visiblcfaw.T)  - 
visiblcfa.T)  has  a  transaction  which  is  a  descendant  of  T,  and  so  is  either  w  or  is  visible  to  T  in  a, 
and  thus  is  in  visiblc(a.T)w.  Ihus  we  have  visiblcfaw.T)  -  visiblcfa.T)w  =  visiblcfa.T)  - 
visiblcfa.'Dw.  As  w  is  not  in  visiblcfa.T).  this  equals  visible(a,T)  -  visible! a.' 1).  By  part  2, 
visiblc(aw.parcnt(  l ))  =  visible!  a.T)w.  and  the  result  follows  by  substitution  in  the  first  identity. 

I 

Now  we  prove  two  lemmas  involving  visibility  and  the  behavior  of  resilient  objects  in  weak  concurrent 
systems. 

Ixmma  63:  l  .ct  a  be  a  weak  concurrent  schedule.  Ixt  RfX)  be  a  resilient  object,  and  let  T  and  T 
be  accesses  to  R(X).  If  T  is  live  and  not  an  orphan  in  a  and  CRHAI'HfT)  occurs  in  a,  then  cither 
T  is  visible  to  T  in  a,  or  else  CRKATKfT)  is  in  the  scope  of  an 
INFORM  -  ABORT-  ATfX)OF(U)  in  a|R(X). 

Proof:  'Ihcrc  arc  two  eases. 

( 1 )  CRKATKfT)  precedes  CRKATKfT)  in  a. 

Assume  T  is  not  visible  to  T  in  a.  Then  Ixmma  59  implies  that  there  is  an 
INFORM  -  AHORT-  AT(X)  operation  for  some  ancestor  of  T.  occurring  after  CRKATKf’O  in  a. 

(2)  CRKATKfT)  precedes  CRKATKfT)  in  a 

Ihcn  I  -cmma  59  implies  that  there  is  either  a  COMMIT  or  an  ABORT  for  some  ancestor  of  T,  in 
a.  Since  T  is  not  an  orphan  in  a,  there  is  a  COMM  IT  for  an  ancestor  of  T  in  a.  Ihcn  I  .cmma  58 
implies  that  T  is  returned  in  a.  a  contradiction.  I 
lemma  64:  let  a  be  a  weak  concurrent  schedule.  I  xt  R(X)  be  a  resilient  object,  let  T  and  T  be 
accesses  to  RfX),  and  let  T’  be  any  transaction.  Assume  that  T  is  not  an  orphan  in  a.  If  an 
operation  w  of  T  precedes  an  operation  w’  of  T  in  a.  w  is  not  in  the  scope  of  an 
INFORM  -  ABORT  and  T  is  visible  to  T”  in  a,  then  T  is  visible  to  T”  in  a. 


Proof:  By  well-formedness,  CRKA'ITfT)  and  CRKATKfT')  arc  operations  in  a.  in  that  order, 
l.ct  a'  be  the  prefix  of  a  ending  with  CRKATKfT).  Ihcn  T  is  live  and  not  an  orphan  in  a'.  By 
Ixmma  63,  T  is  visible  to  T  in  a,  and  so  in  a.  I  .cmma  8  implies  that  T  is  visible  to  T*  in  a.  I 

Ihc  following  lemma  is  straightforward. 

Ixmma  65:  l.ct  a  be  a  weak  concurrent  schedule,  and  let  T  be  a  transaction  which  is  not  an 
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orphan  in  a.  Any  transaction  T  visible  to  T  in  a  is  not  an  orphan  in  a. 

Proof:  If  T  is  an  ancestor  ofT.  the  result  is  immediate.  Otherwise.  COMMIT  operations  appear 
in  a  for  every  proper  descendant  of  lca(T.T')  that  is  an  ancestor  ofT".  By  well-formedness,  none 
of  these  transactions  has  aborted.  Since  the  remaining  ancestors  of  T  arc  also  ancestors  ofT,  and 
the  result  follows.  I 

We  arc  now  ready  to  prove  the  key  lemma  of  this  paragraph. 

I  zinnia  66: 1  .ct  a  he  a  weak  concurrent  schedule,  let  T  be  live  and  not  an  orphan  in  a,  and  let  P 
be  a  resilient  primitive. 

1.  If  P  is  a  transaction  T,  then  visiblc(a,T)|T  is  a  prefix  of  <*|T  and  a  schedule  ofT. 

2.  If  P  is  a  resilient  object  R(X),  then  visiblc(a.T)|R(X)  is  a  prefix  of  undo(a|R(X))  and  a 
schedule  of  basic  object  X. 

Proof:  1.  Immediate  from  Lemmas  11  and  1. 

2.  first,  we  show  that  any  operation  in  visiblcfa,T)|R(X)  also  occurs  in  undo(a|R(X)).  If  *  is  in 
visibiefa,  l  )|R(X),  it  means  that  all  ancestors  of  transaction!  w)  up  to  lcn(transaction(ir).T)  have 
committed.  By  assumption.  T  is  not  an  orphan  in  a.  so  l.cmma  65  implies  that  transaction!*)  is 
not  an  orphan  in  a.  Thus,  by  the  preconditions  of  the  weak  concurrent  controller  there  is  no 
INFORM  -  ABORT  for  any  ancestor  of  transaction!  *)  in  a.  Ihcrcforc,  w  is  in  undo(a|R(X». 

Now  we  consider  any  two  operations  »  and  *’  of  undo(a|R(X)).  where  *  precedes  *’.  Assume 
that  *’  is  in  visiblc(a,T)|R(X).  Let  T'  =  transaction!  w)  and  T  =  transaction!**).  Then  T  is 
visible  to  T  in  o,  and  T  is  not  an  orphan  in  a  by  Lemma  65.  Since  *  is  in  undofa|R(X»,  no 
INFORM  -  ABORT  occurs  at  R(X)  firr  any  ancestor  ofT”  in  a.  with  *  in  its  scope.  Then  Ixmma 
64  implies  that  T*  is  visible  to  T  in  a.  'llius,  *  is  in  visiblc(a.T)|R!X).  It  follows  that 
visiblc(a.T)|R(X)  is  a  prefix  of  undo(a|K(X». 

By  Lemma  61,  a|R(X)  is  a  well-formed  schedule  of  resilient  object  R(X).  Then  the  resiliency 
condition  implies  that  undo(a|R(X))  is  a  schedule  of  basic  object  X.  So  by  Lemma  1. 
visiblcfa,  l)|R(X)  is  a  schedule  of  basic  object  X.  I 

Finally,  we  prove  that,  in  a  weak  concurrent  schedule,  concurrently  executing  transactions  access  disjoint 
sets  of  resilient  objects. 

Lemma  67:  Let  a  be  a  weak  concurrent  schedule,  with  transactions  T  and  T  live  and  not 
orphans  in  a.  Ix:tT*  =  lca(T,T).  Let  0  =  visible! a.T)  -  visiblc(a.T')  and  0*  =  visiblc(a,T)  - 
visiblc(a,T”).  Then  no  resilient  object  has  operations  in  both  0  and  0*. 

Proof:  The  result  is  trivial  if  T  is  an  ancestor  of  T  or  vice  versa.  So  assume  that  leaf  r.T)  is 
neither  T  nor  T.  Let  R(X)  be  a  resilient  object  such  that  both  0  and  0’  contain  operations  of 
R(X).  By  well-formedness,  we  can  assume  without  loss  of  generality  that  there  are  two  accesses  to 
X  (not  necessarily  distinct)  such  that  *  =  CRKATFXU)  and  tp  =  CRKATH(V)  arc  in  0  and  0', 
respectively,  and  neither  U  nor  V  is  visible  to  teafF.T)  in  a.  Also,  we  can  assume  that  w  appears 
in  a  no  later  than  7. 

We  have  that  U  is  visible  to  some  ancestor  ofT  in  a.  and  V  is  visible  to  some  ancestor  ofT  in  a, 
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and  since  T  and  T  arc  not  orphans  in  a.  I  .emma  65  implies  that  no  ancestor  of  U  or  V  has  aborted 
in  a.  Also,  neither  U  nor  V  is  visible  to  lca(T.T')  in  a,  so  it  must  he  that  U  *  V.  Hut  then  v 
precedes  <p  in  a.  and  l  emma  59  implies  that  some  ancestor  of  T  is  committed  in  a.  Then  Ixmma 
57  implies  that  1  is  returned  in  a.  a  contradiction.  I 

7.  Simulation  of  Serial  Systems  by  Concurrent  Systems 

In  this  section,  we  prove  die  main  results  of  this  paper,  that  concurrent  schedules  arc  serially  correct,  and 
that  weak  concurrent  schedules  arc  correct  at  I  fl.  Both  these  results  follow  from  an  interesting  theorem  about 
weak  concurrent  schedules,  which  says  that  the  portion  of  any  weak  concurrent  schedule  which  is  visible  to  a 
live  non-orphan  transaction  is  equivalent  to  (i.c.  looks  the  same  at  all  primitives  as)  a  serial  schedule. 


The  proof  of  this  theorem  is  quite  interesting,  as  it  provides  considerable  insight  into  the  scheduling 
algorithm.  The  proof  shows  not  only  that  a  transaction’s  view  of  a  weak  concurrent  schedule  is  equivalent  to 
some  serial  schedule,  but  by  a  recursive  construction,  it  actually  produces  such  a  schedule.  It  is  interesting  and 
instructive  to  observe  how  the  views  that  different  transactions  have  of  the  system  execution  get  passed  up 
and  down  the  transaction  tree,  as  CRF.ATKS,  COMMITS  and  ABORTS  occur. 

Theorem  68:  l.ct  a  be  a  weak  concurrent  schedule,  and  T  any  transaction  which  is  live  and  not 
an  orphan  in  a.  Then  there  is  a  serial  schedule  p  which  is  equivalent  to  visiblcfa.T). 

Proof:  We  proceed  by  induction  on  the  length  of  a.  The  basis,  length  0,  is  trivial.  Kix  a  of 
length  at  least  1.  and  assume  that  the  claim  is  true  for  all  shorter  weak  concurrent  schedules.  Ixt » 
be  the  last  operation  of  a.  and  let  a  =  a’w.  Fix  T  which  is  live  and  not  an  orphan  in  a.  We  must 
show  that  there  is  a  serial  schedule  ft  which  is  equivalent  to  visiblc(a,T). 

If  it  is  not  a  serial  operation,  then  visiblc(a\T)  =  visiblcfscrialfa’),T)  =  visiblcfscrialfa),T)  = 
visiblcfa.T).  and  the  result  is  immediate  by  induction.  So  we  can  assume  that  w  is  a  serial 
operation.  Also,  if  transaction^ )  is  not  visible  to  T  in  a,  then  visiblcfa.T)  =  visiblcfa’.T).  and 
the  result  is  again  immediate  by  induction.  Thus,  we  can  assume  that  transaction!*)  is  visible  to  T 
in  a.  Also.  T  is  not  an  orphan  in  a. 

There  arc  four  eases. 

(1)  «  is  an  output  operation  of  a  transaction  or  resilient  object 

'Ihcn  the  inductive  hypothesis  implies  the  existence  of  a  serial  schedule  ft'  which  is  equivalent  to 
visiblcfa’.T).  Ixt  /?  =  /3’w.  We  must  show  that  /?  is  equivalent  to  visiblcfa.T)  and  serial. 

Let  P  be  any  primitive.  Then  /?|P  =  P'v\P  =  visiblc(a’.T)»|P  by  inductive  hypothesis.  = 
vi$iblcfa,T)|P,  by  Ixmma  12.  Ihcrcforc,  /?  is  equivalent  to  visiblcfa.T). 

Ixt  *  be  an  output  of  primitive  P.  Then  /3|P  =  visiblc(a,T)|P  by  equivalence,  which  is  a 
schedule  of  P  by  Lemma  66.  I  xmma  4  implies  that  /3  is  serial. 

(2)  v  is  a  CRKATKfT)  operation. 

Then  transaction^)  =  T.  and  so  T  is  visible  to  T  in  a.  Then  I  .emma  55  implies  that  v  is  the  first 
operation  whose  transaction  is  a  descendant  of  T.  Then  by  the  definition  of  visibility,  it  must  be 
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thal  T  =  I'.  Hy  I  cmma  57.  parcnl(T)  is  live  in  a'.  Since  parentfl)  is  not  an  orphan,  the  inductive 
hypothesis  implies  the  existence  of  a  serial  schedule  ft’  which  is  equivalent  to  visible!  a ’.parcnt(T)). 
Let  /3  =  ftv.  We  must  show  that  ft  is  equivalent  to  visiblc(a.T)  and  serial. 

I  cl  P  he  any  primitive.  Then  >3|1*  =  /3'w|l\  -  visible(a’,parcnt(T))Tr|lJ  hy  inductive  hypothesis, 
=  visiblc(a.l  )|P.  by  l.emmaf>2.  Thus.  ft  is  equivalent  to  visible! a‘ T). 
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Consider  any  execution  of  the  serial  system  having  ft'  as  its  operation  sequence,  and  let  s'  be  the 
state  of  die  serial  scheduler  after  ft'.  We  show  thal  ir  is  enabled  in  s’.  That  is.  we  show  that  T  € 
create -requested!  s'),  that  I  $  creatcd(s').  and  that  siblings!  I)  H  crcatcd(s’)  C  returncd(s’). 

Consider  any  execution  of  the  weak  concurrent  system  having  a  as  its  operation  sequence,  and 
let  s  be  the  suite  of  the  weak  concurrent  scheduler  after  a'.  State  s  contains  a  component  sc  for  the 
weak  concurrent  controller  and  a  component  sx  for  the  lock  manager  for  each  object  X. 

If  T  =  T_,  then  T  €  create- requested! s')  by  the  initial  conditions.  If  T  *  Tfl.  then  T  € 
create  -  rcqucstcd(s )  by  the  preconditions  of  the  concurrent  scheduler,  so  a 
RKQUKST  — CRKATTifl’)  operation  occurs  in  a.  'I  Tie  RKQUKST— CRHATHf T)  operation  has 
transaction  parentCD.  and  so  is  in  visiblc(a ’.parent!  I')),  and  thus  is  in  ft'.  Therefore,  T  € 
create  -  requested! s’). 


If  T  €  crcatcd(s').  then  there  is  either  a  CRKATHfO  or  an  ABORT!’!’)  operation  in  ft',  and 
hence  in  a.  In  the  former  ease,  a  would  have  two  such  operations,  while  in  the  latter  ease,  a 
would  have  an  ABORTfO  followed  by  a  CRKATHXT)-  Both  arc  impossible,  so  T  €  crcatcd(s’). 

Assume  U  €  siblings!  T)  D  crcatcd(s’).  Then  there  is  either  a  CRHATHfU)  or  an  ABORT(U) 
operation  in  ft'.  In  the  latter  ease.  U  is  obviously  in  rctumcd(s').  So  suppose  CRKATKXU)  occurs 
in  ft ’,  and  so  in  visible! a'.parcni(T)).  Since  CRHAT  K(U)  occurs  at  U.  U  is  visible  to  parent!’!*)  = 
parcnt(U)  in  a':  thus,  COMMIT(U,u)  occurs  in  a',  for  some  u.  Since  COMMIT(U,u)  occurs  at 
parent!  I  ),  COMMI  I(U,u)  is  in  visiblc(a',parcnt(  I  )),  and  so  in  ft'.  Thus.  U  €  rctumcd(s’). 


(3)  w  is  a  COMM  ITf  I",v)  operation. 

Then  T”  =  parentCD  =  transaction! w)  is  visible  to  T  and  not  an  orphan  in  a.  Also.  T  is  not  an 
orphan  in  a',  by  Lemma  65.  Then  since  a  is  well-formed,  T  is  live  in  a.  and  so  by  Ixmma  57,  T” 
is  live  in  a  and  so  in  a.  Since  T*  is  live  and  visible  to  T.  T"'  is  an  ancestor  of  T.  Since  T  is  live  in 
a.  Lemma  58  implies  that  T  is  not  a  descendant  of  T.  The  inductive  hypothesis  yields  two  serial 
schedules,  ft'  and  ft",  which  arc  equivalent  to  visible! aYO  and  visible! a'.T).  respectively.  Ixt  y 
=  visiblc!/3\T").  Ixt  =  ft'  -  y  and  ft2  =  ft"  -  y.  We  show  that  ft  =  yftxvft2  is  equivalent  to 
visib1c!a,T)  and  serial. 


Lemma  28  implies  that  y  is  a  serial  schedule. 

Since  T’  is  visible  to  T  in  a'.  Lemma  10  implies  that  visible! a’.T’)  =  visible! visib!c!a‘,T).T’). 
which  is  equivalent  to  visiblcf/TX')  =  y;  thus  y  is  equivalent  to  visiblc!o’,T').  Also,  since  T’  is 
visible  to  T  in  a’.  Lemma  10  implies  that  visiblc(a',T")  =  visible! visiblc(a',T"),T'”),  which  is 
equivalent  to  visible!/?’*,’!'").  Thus,  y  is  also  equivalent  to  visiblc!/3'’,T’). 
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Then  by  Lemma  31  (applied  with  scrialfa’)  as  die  schedule  a  hypothesized  in  the  lemma),  yft. 
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and  y/?2  urc  scr'a*  schedules  which  arc  equivalent  to  /?'  and  ft",  respectively. 

We  have  that  visible! a.T")  =  visible!  a'.T'hr  by  I  cnima  62.  which  is  equivalent  to  /)  w,  which  is 
in  turn  equivalent  to  y/?,w.  That  is.  visible! is  equivalent  to  y/SjW. 

Since  /9"  is  equivalent  to  visible(a'.T)  and  y  is  equivalent  to  visiblc(aVr’).  by  I  emma  10,  /L  = 
/?"  -  y  is  equivalent  to  visiblc(a'.T)  -  visible! a ,T").  =  visible! a.T)  *  visiblc(a,T")  by  I  .emma  62. 

Thus.  /?  is  equivalent  to  visiblc(a.T")(visiblc(a.TMvisible(a.T')).  Since  I"  is  visible  to  T  in  a, 
by  Lemma  8.  it  is  easy  to  sec  that  the  same  operations  appear  in  this  schedule  as  in  visiblc(a.T). 
I.ct  P  be  any  primitive.  Then  visible! a.T' ))|P  is  a  prefix  of  visible(a.T)|P,  by  Lemma  66.  It 
follows  that  j8|P  =  visiblc(a.T)|P.  so  that  /?  is  equivalent  to  visiblc(a.T). 

It  remains  to  show  that  /3  is  serial.  'Ibis  follows  from  Lemma  32,  provided  we  can  show  that: 
(3.a)  y/8  ( ir  is  a  serial  schedule. 

(3.b)  T  secs  everything  in  yfi j. 

(3.c)T  secs  everything  in  y/?2, 

(3.d)y  =  visible!  y/3,.T')  =  visib!c(Y/)2,T")and 
(3.c)  no  basic  object  has  operations  in  both  /?  j  and  /?2. 

(3.a)  Consider  any  execution  of  the  serial  system  having  yjSj  as  its  operation  sequence,  and  let  s‘ 
be  a  state  of  die  serial  scheduler  after  y/5..  We  show  that  v  is  enabled  in  state  s’.  Ihan  is,  we  show 
that  (T.v)  €  commit- requested! s'),  that  T  C  rclurncd(s'),  and  that  childrcn(T)  fl 
create  -  requested! s’)  C  rctumcd(s’). 

Consider  any  execution  of  the  weak  concurrent  system  having  a  as  its  operation  sequence,  and 
let  s  be  the  state  of  the  weak  concurrent  scheduler  after  a,  with  components  s£  (the  weak 
controller  state),  and  sx  for  every  object  X  (the  lock  managers). 

Since  the  weak  concurrent  scheduler  is  able  to  perform  COMMN'fT.v)  in  state  s.  it  must  be  that 
(  T.v)  is  in  commit- rcquested(sc).  and  so  it  must  be  that  T  issues  a  RKQUFST-COMMIT(T,v) 
in  a’.  Since  T  is  visible  to  itself,  and  fl'  is  equivalent  to  visiblcfa’.T),  it  follows  that  this 
RKOUHSr-COMMIT(T,v)  operation  also  occurs  in  yfiv  Therefore.  (T\v)  is  in 
commit  -  rcqucstcd(s'). 

Since  a  is  well-formed,  at  most  one  return  operation  for  T  appears  in  a;  thus,  T  is  not  in 
rctumcd(s'). 

Fix  U  €  childrcn(T)  D  create- requested! s’).  Ibcn  RF.QUKST-CREATFXU)  is  performed  at 
T  in  yfiy  and  hence  in  a  ,  so  U  €  create-  rcqucstcd(s  ).  Since  the  weak  concurrent  scheduler  is 
able  to  perform  COMMlT(T,v)  in  state  s,  it  must  be  that  U  €  retumed(sc).  Therefore,  a  return 
operation  for  U  is  performed  at  1",  in  a’.  Since  T  is  visible  to  itself,  and  y/?(  is  equivalent  to 
visiblc(a'.T),  this  implies  that  the  return  for  U  also  occurs  at  1”  in  yfiy  Therefore,  U  is  in 
rctumcd(s'). 

(3.b)  Immediate  from  Ixmma  10. 


(3.c)  Immediate  from  Lemma  10. 


(3.d)  Wc  have  that  y  is  equivalent  to  both  visible!/?'. T')  and  visible!/?”, T'),  and  that  y/3,  and 
iPf  arc  equivalent  to  /?’  and  /?”.  respectively.  By  l  emma  10.  y  is  equivalent  to  both 
visiblefy/?  pT‘)  and  visible! y/?2.T’).  I  Quality  follows. 

(3.c)  Immediate  from  1  .emma  67. 

(4 )ir  is  an  A  HORT(T)  operation. 

Then  T”  =  parcntO")  =  transaction(ir)  is  visible  to  T  in  o.  and  so  is  not  an  orphan  in  a.  by 
Lemma  65.  11100  T  is  live  in  a\  and  by  Lemma  57.  T'  is  live  in  a'  and  so  in  a.  Since  T”  is  live 
and  visible  to  T  in  a,  T  is  a  descendant  of  T’.  Since  T  is  not  an  orphan  in  a.  T  is  not  a  descendant 
of  T.  1110  inductive  hypothesis  yields  two  serial  schedules,  /?’  and  /S’’,  which  arc  equivalent  to 
visiblciaYl"')  and  visiblcfa’.T),  respectively.  Let  =  /?”  -  /S’.  Wc  show  that  /3  =  /?’*/?,  is 
equivalent  to  visiblc(a.T)  and  serial. 

By  I  .emma  31.  /S'/3 ,  is  a  serial  schedule  which  is  equivalent  to  /S’’. 

Let  P  be  a  primitive  other  than  T*.  'Ihcn  /3|P  =  /S’/3||P  =  /3*’|P  =  visiblcfaYOIP,  = 
visiblc(a,T)|P  by  Lemma  62.  Also,  since  T'  is  visible  to  T  in  a,  visiblc(a.T)|T'  = 
visiblc(a.T’)rr’,  =  visiblc(a'.T'’)ir|T'  by  Lemma  62.  =  /S’w|T*  =  /Sfl"*-  lhus/3  is  equivalent  to 
visiblcfa.T). 

It  remains  to  show  that  /3  is  serial.  Ihis  follows  from  Ixmma  33.  provided  wc  can  show  that: 

(4.a)  /S’ w  is  a  serial  schedule. 

(4.b)  T  secs  everything  in  /3 ’/?  p  and 
(4.c)  /?’  =  visiblcf/S’.T’)  =  visiblcf/S’^.T”). 

(4.a)  Consider  any  execution  of  the  serial  system  having  /S’  as  its  operation  sequence,  and  let  s’ 
be  a  state  of  the  serial  scheduler  after  /S’.  Wc  show  that  v  is  enabled  in  state  s’.  That  is.  wc  show 
that  I”  €  create- requested! s'),  that  T  C  crcatcd(s’),  and  that  siblings(T)  PI  crcatcd(s’)  C 
rctumcd(s’). 

Consider  any  execution  of  the  weak  concurrent  system  having  o  as  its  operation  sequence,  and 
let  s  be  the  state  of  the  weak  concurrent  scheduler  after  a\  with  components  sc  (the  weak 
controller  state),  and  sx  for  every  object  X  (the  lock  managers). 

Since  the  weak  concurrent  scheduler  is  able  to  perform  ABORTfT)  in  state  s.  it  must  be  that  T 
is  in  create -rcqucsted(sc),  and  so  it  must  be  that  T”  issues  a  RHQUHS  r-CRHATHO’’)  in  a’. 
Since  T”  is  visible  to  itself,  and  /?'  is  equivalent  to  visiblcfa’.T),  it  follows  that  this 
RKQUPST-CRKA'rPXT)  operation  also  occurs  in  /S’.  Therefore.  T  is  in  create- requestedfs’). 

Since  a  cannot  contain  two  ABOR'l’(T)  operations,  there  cannot  be  an  ABORT(T)  operation  in 
o’,  and  so  there  cannot  be  one  in  /?’.  Assume  that  there  is  a  CRKATPX'O  in  P'.  ’ITicn  T  is  visible 
to  T’  in  a\  so  COMM  ITCH  occurs  in  o’.  But  then  a  COMMITfl”)  and  and  ABORTCT)  both 
occur  in  a,  which  cannot  occur.  Therefore,  there  is  neither  an  ABORTCI”)  nor  a  CRHATPXT)  in 
/S’,  and  so  T  is  not  in  crcatcd(s’). 

Fix  U  €  siblings(T)  D  crcatcd(s’).  Then  there  is  a  CRFA TK(U)  in  /S’.  But  then  U  is  visible  to 
T”  in  o’,  so  that  a  COM  MU’  for  U  occurs  in  o’,  and  hence  (because  parcnt(U)  is  visible  to  T*  in 


a’)  a  COMMIT  for  U  occurs  in  ft'.  I'hcrcforc.  U  €  rctumcd(s'). 

(4.b)  Immediate  from  l  .cmma  10. 

(4.c)  Ihc  first  equality  follows  from  l.cmma  10.  Clearly.  /}'  =  visibktf/T.T")  is  a  prefix  of 
visible!/?'/?  pT").  l-quality  follows  because  any  operation  in  /? ,  visible  to  T”  in  /?'/? ,  would  also  be 
visible  to  T”  in  a\  and  so  would  be  in  /?'  and  not/?,.  I 

Corollary  69:  Hvery  weak  concurrent  schedule  is  serially  correct  for  every  non-orphan  non- 
access  transaction. 

Proof:  l  et  a  be  a  weak  concurrent  schedule.  Ixt  T  be  a  non-access  transaction  that  is  not  an 
orphan  in  a.  We  must  show  that  afl  is  a  serial  schedule.  Note  that  T  is  not  an  orphan  in  any 
prefix  of  a. 

There  are  three  eases: 

(1)  afl’ is  empty. 

Then  the  result  is  trivial. 

(2)  T  is  live  in  a. 

Then  'Ihcorem  68  yields  a  serial  schedule  /?  that  is  equivalent  to  visiblc(a,T).  Thus,  a|T  = 
visiblc(a,T)|T  =  fl\V.  which  suffices. 

(3)  T  is  a  transaction  which  is  live  in  some  proper  prefix  of  a. 

Since  a  is  well-formed,  a  has  a  prefix  a’w.  where  w  is  a  COMMIT  operation  for  T.  a*|T  »  a|T 
and  T  is  live  in  a'.  Ihcn  Ihcorem  68  yields  a  serial  schedule  fi  that  is  equivalent  to 
visiblc(aV T)|T.  Ihus,  a|T  =  o’ fl’  =  visiblc(a’,T)|T  =  /?P which  suffices.  I 

Now.  since  10  cannot  become  an  orphan  (having  no  ancestors  to  abort),  our  first  major  correctness  result  is 
immediate. 

Corollary  70:  Hvery  weak  concurrent  schedule  is  serially  correct  forTQ. 

Having  proved  correctness  properties  for  weak  concurrent  schedules,  we  arc  now  ready  to  prove  the 
correctness  of  concurrent  schedules. 

Ixmma  71:  Hvery  concurrent  execution  is  a  weak  concurrent  execution. 

Proof:  Ihc  proof  is  by  induction  on  execution  length,  with  a  trivial  basis.  I  .ct  a  =  a’.s’.w.s  be  a 
concurrent  execution  with  (s’,w,s)  a  single  step  of  the  concurrent  system,  and  assume  the  lemma 
holds  for  a.  l>ct  s'c  and  sc  denote  the  suites  of  the  concurrent  controller  in  system  states  s*  and  s. 

If  v  is  any  operation  other  than  an  AliORT,  the  result  is  immediate,  since  the  prc-  and 
postconditions  for  all  other  operations  arc  identical  in  the  concurrent  and  weak  concurrent 
systems.  Assume  that  w  is  an  ABORT(T).  We  must  show  that  T  €  crcatc-rcquestcd(s,c)  - 
rctumcd(s’c). 

Since  w  is  enabled  in  state  s’c  in  the  concurrent  controller,  T  €  (create- rcqucstcd(s’)  - 
crcatcd(s'c))  U  (commit-rcqucsted(s’c)  -  rctumcd(s'  )).  If  T  is  in  create- rcqucstcd(s^)  - 
crcatcd(s’c).  Lemma  45  implies  that  a  con  pins  no  CRHATHfl’)  or  AHORT(T)  operation.  By 
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well-formedness,  a'  also  contains  no  COMMI  T  operation  for  T.  and  the  result  follows  from 
I  .emma  45.  On  the  other  hand,  if  T  is  in  commit-rcqucstcd(s'c)  -  rcturncd(s’f).  I  .emma  45  implies 
that  a  RHQUKST-C'OMMTT  operation  for  I  occurs  in  a'.  By  well-formedness,  this  is  preceded 
by  a  CKFATFfT)  operation,  and  by  the  concurrent  controller  precondition,  this  is  preceded  by  a 
RI3QUTST— CRFATFforT.  Finally,  again  by  I  .emma  45.  the  result  follows.  ■ 

Now  we  can  prove  the  second  major  result  of  the  paper. 

Corollary  72:  Kvery  concurrent  schedule  is  serially  correct. 

Proof:  I  . ct  a  be  a  concurrent  schedule.  Then  a  is  also  a  weak  concurrent  schedule,  by  I  .emma 
71,  and  is  well-formed,  by  Lemma  61.  We  must  show  that  a  is  serially  correct  for  every 
transaction  T.  ’There  arc  three  eases: 

(1)  afl'is  empty. 

Then  the  result  is  trivial. 

(2)  T  is  live  in  a. 

By  Lemma  50.  all  of  Ts  ancestors  arc  live  in  a.  so  that  T  is  not  an  orphan  in  a.  Then  Corollary  69 
yields  the  result 

(3)  T  is  a  transaction  which  is  live  in  some  proper  prefix  of  a. 

By  I  .emma  51.  a  has  a  prefix  aw,  where  w  is  a  return  operation  for  T.  a‘|T  =  a|T  and  T  is  live  in 
a\  By  Lemma  50.  all  of  Ts  ancestors  arc  live  in  a\  so  T  is  is  not  an  orphan  in  a'.  'Then  Corollary 
69  implies  that  a'  is  serially  correct  for  T,  so  that  a  is  serially  correct  for  T.  I 

For  completeness,  we  include  an  analog  of  Thcorcm  68  for  concurrent  schedules. 

Theorem  73:  I  .ct  a  be  a  concurrent  schedule,  and  T  any  transaction  which  is  live  in  a.  'Then 
there  is  a  serial  schedule  /?  which  is  equivalent  to  visiblc(a,T). 

Proof:  I  .emma  71  implies  that  a  is  a  weak  concurrent  schedule.  Since  1'  is  live  in  a.  I  .emma  50 
implies  that  1'  is  not  an  orphan  in  a.  ’Then  'Theorem  68  yields  the  result.  I 

8.  Discussion 

In  this  paper,  we  have  presented  a  formal  model  for  describing  nested  transaction  systems  and  their 
properties.  The  model  has  many  features  that  we  believe  make  it  a  major  contribution  to  the  understanding 
of  transaction  systems,  and  we  highlight  some  of  these  below. 

First,  the  entire  model  is  based  on  a  very  general  and  very  simple  underlying  model  for  concurrent 
computation,  the  I/O  automaton  model.  The  general  definitions  and  properties  of  this  underlying  model 
provide  the  necessary  underpinnings  for  our  entire  transaction  modelling  effort  This  modelling  is  very  easy 
to  learn  and  use.  and  its  usefulness  extends  much  beyond  transaction  systems,  Thus,  it  seems  to  us  to  be  a 
very  satisfactory  foundation  for  our  work. 

Our  transaction  system  model  permits  simple,  yet  completely  rigorous  description  of  concurrency  control 
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algorithms  in  ways  which  correspond  very  closely  to  the  usual  informal  ways  of  understanding  the  algorithms. 
The  important  components  of  transaction  systems,  the  transactions,  data  and  schedulers,  arc  described 
explicitly,  which  greatly  facilitates  reasoning  about  them. 

There  is  a  substantial  amount  of  work  in  this  area  which  docs  not  represent  all  of  these  components 
explicitly,  but  only  implicitly,  by  properties  of  their  behavior  [Ly.BHG.Go.  for  example).  Ihcre  arc  problems 
with  this  approach.  A  key  ingredient  that  is  usually  absent  from  such  implicit  models  is  a  clear  notion  of 
"causality",  describing  how  particular  actions  (operations)  arc  triggered  by  other  actions  or  states.  In  contrast, 
our  explicit  representation  of  all  system  components  as  I/O  automata  makes  it  easy  to  understand  exactly 
what  causes  all  operations  to  occur.  When  causality  is  important  in  reasoning  about  algorithms,  as  in  (Go), 
implicit  models  can  be  extraordinarily  difficult  to  use.  Kven  in  cases  where  implicit  models  can  be  used,  we 
see  the  present  work  as  providing  a  formal  and  intuitive  basis  for  that  work. 

Our  model  represents  transactions  as  essentially  arbitrary  automata,  subject  only  to  simple  syntactic 
constraints.  Ibis  approach  is  much  more  general  than  representing  them  as  programs  in  some  particular, 
overly-constrained  language. 

Ibc  I/O  automata  model  permits  description  of  algorithms  in  an  abstract  form  which  is  not  tied  to  a 
particular  programming  language  or  system,  and  which  allows  maximum  nondeterminism.  An 
implementation  of  an  algorithm  for  a  particular  system  will  generally  restrict  the  nondeterminism  allowed  in 
our  presentation,  because  of  the  need  to  tailor  the  implementation  to  the  requirements  of  a  particular 
environment.  However,  since  the  implementation  is  just  a  restriction  of  the  abstract  algorithm,  correctness 
properties  of  the  algorithm  within  our  model  will  hold  a  fortiori  for  the  implementation. 

Formulating  nested  transaction  systems  as  I/O  automata  permits  precise  formulation  of  the  correctness 
conditions  to  be  satisfied  by  concurrency  control  algorithms;  those  correctness  conditions  can  be  stated  at  the 
transaction  interface,  an  interface  which  docs  not  contain  explicit  information  about  object  representation. 
Because  of  this  choice  of  interface,  the  correctness  conditions  can  be  stated  in  a  robust  way:  the  same 
conditions  can  be  useful  for  describing  the  properties  of  many  different  kinds  of  algorithms,  some  of  which 
manipulate  the  data  in  very  different  ways.  Also,  the  correctness  conditions  can  be  described  in  a  way  that  is 
meaningful  to  a  user  of  the  system. 

'Ibc  particular  correctness  conditions  that  we  describe  in  this  paper  involve  serial  correctness  at  transaction 
interfaces.  We  believe  that  these  particular  correctness  definitions  arc  very  interesting,  and  will  be  useful  for 
describing  the  correctness  of  most  of  the  usual  algorithms  studied  in  the  concurrency  control  area.  Ibat  is.  the 
same  conditions  appear  to  be  the  right  ones  to  use  to  describe  correctness  of  many  different  kinds  of 


algorithms,  including  those  that  use  locking,  timestamps,  multiple  versions,  and  replicated  data. 

Ihc  model  permits  rigorous  correctness  proofs  to  be  carried  out  for  concurrency  control  algorithms  in  ways 
that  follow  intuitive  understanding  of  the  algorithms.  For  example,  in  this  paper,  we  have  used  the  model  to 
describe  and  show  the  correctness  of  a  very  important  nested  transaction  concurrency  control  algorithm.  Our 
correctness  proofs  arc  constructive  and  provide  considerable  intuition  about  the  workings  of  the  algorithm. 
In  contrast  to  most  correctness  proofs  for  concurrent  algorithms,  our  proofs  arc  not  voluminous  low-level 
ease-analyses;  rather,  they  consist  of  a  large  number  of  clear  and  natural  lemmas  about  the  behavior  of  the 
algorithm.  These  lemmas  can  be  undcrsnxid  individually,  and  build  upon  each  other  in  the  manner  of  good 
mathematics.  Many  of  the  lemmas  should  be  reusable  in  extensions  of  this  work  as  well. 

A  successful  model  of  nested  transactions  should  contain  the  classical  theory  as  a  special  ease,  in  a  way 
which  is  natural  and  sheds  some  light  on  that  ease.  We  believe  that  our  model  has  contributed  much  to  the 
classical  theory.  For  example,  the  I/O  automaton  model  provides  a  general  underlying  model,  a  missing 
component  of  the  classical  theory.  Also,  our  explicit  and  general  modelling  of  the  transactions  unifies  the 
earlier  collection  of  somewhat  arbitrary  approaches.  Our  use  of  the  transaction  interface  for  stating 
correctness  conditions  is  also  an  improvement 

Another  contribution  to  the  classical  theory  is  in  motivating  scrializability  as  a  correctness  condition. 
Scrializability  consists  of  two  criteria;  individually,  each  transaction  must  see  a  consistent  state,  and  together, 
they  must  appear  to  run  in  a  serial  order.  (A  schedule  in  which  each  transaction  reads  and  writes  the  initial 
state  of  the  database  provides  a  consistent  state  to  each  transaction,  but  is  not  serializable.)  Why  is  this  second 
ordering  property  a  part  of  the  generally  accepted  correctness  condition  of  the  classical  theory?  Clearly, 
because  of  implicit  nesting  in  the  context  of  the  transaction  system.  In  practice,  transactions  perform  tasks  on 
behalf  of  some  external  entity  or  entities,  which  may  expect  one  transaction  to  see  the  results  of  the  next  In 
the  natural  formulation  of  classical  systems  within  the  present  model,  the  classical  transactions  arc  children  of 
T0.  with  data  accesses  as  their  only  children.  The  root  is  an  explicit  representation  of  the  external 
environment  in  which  the  system  runs.  Thus,  the  ordering  property  of  scrializability  is  a  natural  consequence 
of  the  requirement  that  all  transactions  see  serial  schedules,  including  T0.  It  docs  not  have  to  be  introduced  as 
an  independent  requirement  in  need  of  separate  justification. 

By  now.  there  has  been  a  large  amount  of  systems  design  and  algorithms  work  that  uses  or  implements 
nested  transactions.  It  seems  likely  that  these  ideas  will  form  the  basis  of  future  programming  languages  for 
distributed  computing.  However,  there  is  currently  a  problem  with  the  presentation  of  this  work.  Some  of 
these  algorithms  arc  presented  in  the  context  of  specific  systems  and  programming  languages.  Very  useful 
and  general  ideas  arc  too  intimately  connected  with  details  of  the  systems  to  be  fully  appreciated,  particularly 
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for  readers  with  only  a  passing  understanding  of  those  systems.  This  level  of  detail  also  makes  careful 
reasoning  about  the  algorithms  very  difTicult. 

We  believe  that  our  model  has  provided  die  necessary  framework  and  some  of  the  necessary  vocabulary,  for 
describing  this  work  in  a  clear  and  unambiguous  way.  We  arc  currently  studying  much  of  this  work  on 
systems  design  and  algorithms  using  our  model,  and  our  preliminary  results  indicate  that  it  works  very  well. 

Throughout  the  paper,  we  have  described  connections  with  other  people's  work  as  appropriate.  Here,  we 
mention  some  of  the  particular  modelling  work  that  relates  most  closely  to  ours,  and  describe  the  connections 
in  more  detail. 

First,  the  pioneering  work  of  Bernstein  and  Goodman  [BG.  etc.]  has  had  a  strong  influence  on  this  work. 
Quite  early,  they  recognized  the  need  for  a  model  for  single-level  transaction  systems,  that  would  have  many 
of  the  characteristics  which  we  have  sought  for  nested  transaction  systems.  They  have  carried  out  extensive 
research  on  precise  understanding  of  single-level  transaction  concurrency  control  algorithms.  They  have 
presented  formal  statements  of  correctness  conditions,  in  terms  of  scriali/ability  of  the  accesses  to  data  objects 
by  different  transactions.  They  have  described  some  concurrency  control  algorithms  with  precision,  and  have 
proved  correctness  of  some  algorithms,  using  a  lemma  which  characterizes  scriali/ability  by  absence  of  cycles 
in  a  certain  dependency  relation.  Their  work  has  gone  a  long  way  toward  providing  precise  understanding  of 
the  work  in  this  area. 

However,  the  particular  models  used  by  Bernstein  and  Goodman  have  some  problems  which  limit  their 
applicability.  For  instance,  the  basic  correctness  condition  is  stated  in  terms  of  the  interface  between  the  data 
objects  and  the  algorithm.  There  are  many  algorithms  which  handle  objects  in  very  different  ways,  c.g.  using 
multiple  versions,  or  making  multiple  copies  in  order  to  permit  "backing  out"  of  operations.  Since  these 
algorithms  do  not  preserve  the  specified  object  interface,  they  would  not  be  considered  correct  under  the 
same  correctness  condition.  Thus,  the  correctness  condition  must  be  modified.  Another  limitation  is  that  the 
proof  technique,  which  involves  proving  absence  of  cycles,  is  a  proof  by  contradiction;  it  docs  not  give  much 
insight  into  the  operation  of  the  algorithms.  For  many  reasons,  it  is  not  at  all  dear  how  to  extend  these 
frameworks  to  handle  nesting  of  transactions. 

Karlicr  attempts  in  [Ly.Go.BBGLS]  to  model  nested  transactions  have  made  significant  contributions.  For 
example,  [Ly]  contains  a  language-independent  model,  which  is  used  to  give  precise  correctness  conditions 
and  a  proof  for  a  locking  algorithm.  Many  of  the  ideas  in  that  work  have  been  useful  in  providing  a 
vocabulary  for  talking  about  nested  transactions.  However,  attempts  to  extend  the  model  of  [Ly]  to  handle 
correctness  of  orphans  [Go]  demonstrate  that  it  is  not  sufficiently  expressive.  Certain  aspects  of  the  model 


lead  to  technical  difficulties:  for  example,  it  fails  to  model  the  transactions  explicitly,  using  instead  a 
specification  of  their  behavior.  Our  new  model  builds  on  the  strengths  of  the  earlier  work,  while  managing 
(we  believe)  to  avoid  its  weaknesses. 

Finally,  the  very  recent  work  in  (BI)G]  proposes  another  general  model  for  nested  transactions.  While  on 
the  surface  the  models  appear  quite  different,  they  are  actually  "compatible",  in  that  the  concepts  described  in 
[BBG]  seem  to  be  easily  definable  within  our  model.  The  style  of  the  model  in  |DDG]  is  different  from  ours: 
their  work  models  transactions  and  the  scheduler  implicitly,  for  instance.  However,  we  belie  c  that  their 
important  axiomatic  statements  of  properties  can  be  described  as  assumptions  and  lemmas  about  behaviors  of 
components  in  our  model.  Also,  the  partial  orders  which  they  use  to  model  executions  can  actually  be 
defined  simply  and  directly  in  terms  of  our  linearly-ordered  executions.  Ihcrc  arc  many  points  of  agreement: 
the  use  of  the  transaction  interface  for  stating  correctness  conditions,  and  the  use  of  the  virtual  root 
transaction  1'0,  to  mention  two. 

On  the  other  hand,  the  emphasis  in  [BBGJ  is  on  a  different  example  than  the  one  studied  in  this  paper. 
They  consider  multiple  levels  of  abstraction  for  the  data,  and  regard  transactions  at  any  level  of  the 
transaction  tree  as  accesses  to  data  at  a  corresponding  level  of  abstraction.  This  view  meshes  quite  well  with 
our  model,  where,  for  example,  we  use  the  same  CRKATH  notation  for  creation  of  a  transaction  and 
invocation  of  an  operation  on  data.  Their  paper  clarifies  the  concurrency  control  requirements  for  data  at 
different  levels,  when  the  correctness  condition  is  serial  correctness  at  Tfl.  We  hope  and  expect  that  it  will  be 
easy  to  restate  their  results  as  claims  about  our  model. 

We  note  that  the  work  in  [BRG]  only  treats  concurrency  control,  but  docs  not  address  the  very  critical  and 
difficult  issues  of  resiliency. 

9.  Further  Work 

Ihis  paper  is  an  embarkation  on  a  major  project  to  formulate  a  unified  presentation  of  the  most  important 
algorithms  for  concurrency  control  and  resiliency,  especially  those  for  nested  transactions.  So  far.  we  have 
defined  a  general  framework  meeting  the  requirements  outlined  above.  We  have  demonstrated  the  power  of 
this  framework  by  using  it  to  specify  two  correctness  conditions  for  nested  transactions,  to  present  two  locking 
algorithms  for  implementing  nested  transactions,  and  to  prove  that  the  algorithms  satisfy  their  respective 
requirements. 

Future  extensions  to  this  work  will  include  treatment  of  many  other  algorithms  in  the  same  framework. 
Among  the  algorithms  we  will  consider  arc  timestamp  and  multivcrsion  algorithms,  algorithms  which  take 
advantage  of  special  properties  of  the  transactions  and  objects  (semantic  information),  algorithms  far  orphan 


management,  and  algorithms  which  use  replicated  data  objects.  Although  our  focus  so  far  has  been  on  nested 
transactions,  we  believe  that  our  viewpoint  contributes  new  insight  to  the  special  ease  of  single-level 
transactions  as  well:  thus,  we  will  examine  algorithms  for  non-ncstcd  transactions  as  well  as  nested 
transactions. 

We  arc  particularly  interested  in  studying  algorithms  which  give  rise  to  live  orphans,  i.c.  live  transactions 
whose  ancestors  have  aborted  |Go,l.i,Wa.HM].  Our  serial  correctness  condition  provides  a  formal  definition 
of  orphan  correctness  -  that  all  transactions  (including  orphans)  "see  consistent  data”  (Go].  In  fact,  in  work 
currently  in  progress  (HI. MW),  we  arc  describing  and  proving  correctness  of  several  of  the  recently-developed 
algorithms  for  orphan  management.  This  work  now  seems  to  be  quite  easy,  given  the  foundation  provided  by 
the  present  paper.  In  fact,  some  of  the  key  results  of  this  paper  arc  used  as  lemmas  in  that  work. 

Another  direction  of  interest  is  the  explicit  representation  of  distribution  within  the  model.  It  is  fairly 
natural  to  model  each  transaction  and  object  as  located  at  different  sites,  each  with  a  local  automaton 
representing  the  resident  portion  of  the  (distributed)  scheduler.  These  automata  would  communicate  with 
each  other  in  order  to  implement  the  (centralized)  scheduler  studied  here.  ITie  natural  next  step  would  be  to 
model  failure  resilience,  as  various  components  lose  information  or  fail  altogether. 

The  reader  might  have  noted  that  our  correctness  conditions  do  not  guarantee  anything  about  the  system 
making  progress,  but  only  about  "safety"  properties.  Further  work  is  needed  to  incorporate  guarantees  of 
progress.  'Ihis  work  is  likely  to  be  difficult,  however.  Only  recently,  in  [I.T],  have  we  achieved  what  we 
consider  to  be  a  satisfactory  understanding  of  the  eventuality  and  fairness  issues  for  the  basic  I/O  automaton 
model,  so  that  we  can  even  formulate  the  conditions  we  want  to  satisfy.  But  even  with  the  ability  to  state  such 
conditions,  the  algorithmic  issues  still  seem  difficult 
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